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[57] ABSTRACT 

An interrupt managing system for a computer system in 
which resources are managed by a real-time operating 
system. Hie interrupt managing system has managed inter- 
rupt storage unit in which information regarding interrupts 
to be managed by the real-time operating system is stored, 
interrupt disabling processing unit for reading out the infor- 
mation stored in the managed interrupt storage unit and 
disabling an interrupt designated by the information in order 
to perform exclusive control needed for system call 
processing, and interrupt enabling processing unit for 
enabling the disabled interrupt According to the interrupt 
managing system, an asynchronous interrupt which does not 
have an influence on the resource management by an OS is 
enabled even during a system call processing and an inter- 
rupt which does not issue a system call can be processed 
without any delay. 
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INTERRUPT MANAGING SYSTEM FOR 
REAL-TIME OPERATING SYSTEM 

BACKGROUND OF THE INVENTION 

1. Held of the Invention 

This invention relates to an interrupt managing system for 
a real-time operating system (real-time OS). 

2. Description of the Prior Art 

In a computer system wherein resources and processes are 
controlled by a real-time OS. also interrupt processing for an 
asynchronous interrupt which may be generated by various 
factors is managed by the real-time OS. A software routine 
for executing interrupt processing is normally called an 
interrupt handler. In a conventional computer system which 
is controlled by a real-time OS. in order to allow a system 
call to the OS to be issued from all interrupt handlers, it is 
common for the real-time OS to manage all interrupts 
collectively. The system call signifies an instruction issued 
by a task or an interrupt handler in order to request a service 
provided by the OS. 

FIG. 1 shows a conventional computer system controlled 
by a real-time OS. To a CPU (Central Processing Unit) 51. 
an interrupt controller 50 which transmits generation of an 
interrupt event to the CPU 51 and a main storage 40 are 
connected. An interrupt A from an interrupt factor 48 and 
another interrupt B from another interrupt factor 49 are 
inputted to the interrupt controller 50. An OS 45 is resident 
in the main storage 40, and a routine 41 of a task A. another 
routine 42 of another task B. an interrupt handler 44 which 
starts in accordance with the occurence of the interrupt A and 
another interrupt handler 43 which starts in accordance with 
the occurence of the interrupt B are stored in the main 
storage 40. It is assumed that among them, the interrupt 
handler 44 corresponding to the interrupt A executes its 
software routine to issue a system call to the OS 45. but the 
interrupt handler 43 corresponding to the interrupt B does 
not issue a system call in its software routine. Further, the 
OS 45 includes, in the inside thereof, interrupt disabling 
processing means 46 for putting the CPU 51 into an interrupt 
disabling condition, and interrupt enabling processing 
means 47 for putting the CPU 51 into an interrupt enabling 
condition. 

By the way. some system call processing routines 
executed by the OS in response to generation of a system 
call necessitate exclusive control in order to prevent such 
conflict of resources that the same resource is handled in 
response to system calls generated from different interrupt 
handlers. The exclusive control is realized by setting a 
particular interval of the system call processing routine as 
interrupt disabling interval and inhibiting acceptance of any 
interrupt by the CPU 51 during execution of the routine 
within the interrupt inhibition interval. 

The interrupt processing of the above computer system is 
described below with reference to FIG. 2. Here, description 
is given of the case wherein a system call to the OS 45 is 
issued by the task A during execution of the task A and then, 
within an interrupt disabling interval in the system call 
processing, the interrupt A is inputted from the interrupt 
factor 48 to the interrupt controller 50 and then the interrupt 
B is inputted from the interrupt factor 49 to the interrupt 
controller 50. In FIG. 2. each routine being executed by the 
CPU 51 is indicated by a thick line. Further, EI (enabling 
interrupt) represents an interrupt enabling interval, and DI 
(disabling interrupt) represents an interrupt disabling inter- 
val. 

It is assumed that, during execution of the routine 41 of 
the task A while the CPU 51 is in an interrupt enabling 
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condition, a system call to the OS 45 is issued at time 52. As 
a result the processing by the CPU 51 passes into the OS 45, 
by which system call processing is thereafter performed. In 
order to perform such exclusive processing as described 

5 above in the processing in the OS 45. interrupt disabling 
processing is executed at time 53 by the interrupt disabling 
processing means 46. Consequently, an interruption dis- 
abling interval is started. The interrupt disabling processing 
is performed, for example, by executing an interrupt dis- 
abling instruction (e.g., "DI" instruction of some kinds of 
CPUs) of the CPU 51. 

Here, if the interrupt A (indicated as "INT A") from the 
interrupt factor 48 is inputted to the interrupt controller 50 
at time 54 within the interrupt disabling interval in the 

15 system call processing, the interrupt controller 50 outputs an 
interrupt request to the CPU 51. However, since the CPU 51 
is within the interrupt disabling interval, the CPU 51 does 
not transfer the processing to the interrupt handler 44 but 
continues to execute the system call processing. Further, if 

20 the interrupt B (indicated as 'TNT B") is inputted from the 
interrupt factor 49. which is another interrupt factor, at time 
55 within the interrupt disabling interval, then the process- 
ing of the interrupt handler is held similarly as in the case of 
the interrupt A. The interrupt handler 43 does not generate 

25 a system call in the inside thereof at all, and even if 
processing by the interrupt handler 43 is executed during the 
system call processing, no conflict occurs with the resources 
managed by the OS 45. Here, however, the interrupt pro- 
cessing by the interrupt handler 43 is held by the OS 45. 

30 After the processing for which exclusive control is 
required in the system call processing comes to an end. 
interrupt enabling processing is executed by the interrupt 
enabling processing means 47. Here, it is assumed that the 
interrupt inhibiting processing comes to an end and an 

35 interrupt enabling interval is started at time 56. 
Consequently, the interrupt handler 44 is executed only after 
the interrupt enabling processing is started, and the interrupt 
handler 43 is executed after completion of processing of the 
interrupt handler 44. The interrupt enabling processing is 

40 performed, for example, by executing an interrupt enabling 
instruction (e.g.. "ET instruction) of the CPU 51. 

After all. the processing when an asynchronous interrupt 
event occurs in the present system is performed in such a 
manner as illustrated in FIG. 3. In particular, the processing 

45 branches at step S15 depending upon whether the condition 
of the CPU 51 is the interrupt enabling condition (£1) or the 
interrupt disabling condition (DI). If the condition of the 
CPU 51 is the interrupt enabling condition, then the pro- 
cessing is transferred to a corresponding interrupt handler 

so (step S16), and then, after the processing of the interrupt 
handler comes to an end. the processing returns to that 
executed prior to the interrupt (step S17), thereby complet- 
ing the series of processes. On the other hand, if the 
condition of the CPU 51 is the interrupt disabling condition 

55 at step S15. interrupt handler processing is held until the 
interrupt enabling condition is entered subsequently (step 
S18). Then, after the interrupt enabling condition is entered, 
the processing advances to step S16 described above. 
In the interrupt managing method by the conventional 

60 real-time OS described above, the OS collectively performs 
enabling/disabling processing for all interrupt factors. In 
particular, within an interrupt disabling interval, all inter- 
rupts are rejected. Consequently, a limitation by an interrupt 
disabling time arising from the OS exists equally to all 

65 interrupt factors, which is one of the obstacles to an 
improvement in operation efficiency of the system. Further, 
this limitation makes an obstacle to implement a real-time 
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OS into a system in which an interrupt for which no delay FIG. 3 is a flow chart illustrating processing by the 

of the interrupt processing is allowed is present or another computer system shown in FIG. 1 when an interrupt occurs; 

system in which a timer interrupt in a period shorter than a FIG. 4 is a block diagram showing the construction of a 

maximum value of the interrupt disabling time prescribed by computer system to which an interrupt managing method of 
the real-time OS is present. Thus the limitation is a cause of 5 a fra embodiment of the present invention is applied; 

narrowing the range in apphcation of the real-time OS. FIG. 5 is a timing chart illustrating processing by the 

o ^T/^^o ^o^'^k^^ N ?' Hei " com P uter svstem of * c ** embodiment when interrupts 

2-220138 (JP, A, 2-220138), now abandoned, discloses a successively occur; 

different technique wherein, when a system call is issued mr , . . * , _ . . L ^ 

within a system call disabling interval in processing of an io ™" 6 18 * *7 ^ 6 f n f w " l « b * mc 

interrupt handler by an external interrupt ttiat is, within a COmputer system of me fost embodimeDt when mtcnru P t 

software interrupt disabling intervaL the system call pro- occurs » 

cessing is delayed until the system call disabling interval HG - 7 is a fiow ABri illustrating processing by the 

comes to an end, giving priority to the interrupt processing. computer system of the first embodiment when another 

With this technique, however, since an interrupt takes pre- is interrupt occurs; 

cedence over a system call only within a system call FIG. 8 is a block diagram showing the construction of a 

disabling interval explicitly designated in an interrupt computer system to which an interrupt managing method of 

handler, a limitation by an interrupt disabling time still exits. a second embodiment of the present invention is applied; 

SUMMARY OFTHF TNVFNXTOTST mG ' 9 is a timin 8 iwis**ing processing by the 

SUMMARY OF THE INVENTION 20 computcr system ofthe second embodiment when interrupts 

It is an object of the present invention to provide an successively occur, 
interrupt managing system wherein an interrupt which does FIG. 10 is a flow chart illustrating processing by the 
not have an influence on the resource management by an OS computer system of the second embodiment when an inter- 
is enabled even during a system call processing and an rupt occurs; and 

interrupt which does not issue a system call can be processed 25 nG U j, a flcw mustratm g processing by the 

without any delay. computer system OS of the second embodiment when 

According to the present invention, the above object is another interrupt occurs, 
achieved by an interrupt managing system for a computer 

system which includes a CPU and wherein resources are DESCRIPTION OFTHE PREFERRED 

managed by a real-time operating system and an asynchro- 30 EMBODIMENTS 
nous interrupt to the CPU occurs, the interrupt managing 

system comprises managed interrupt storage means in which First Embodiment 

Mormation regarding interrupts to be managed by the mG 4 ^ 

real-tin* operadng system is stared mterrupt disabhng men , of ^ ^^c^-^ applieA Xo a cp^Z 

processing ineaas for reading out the mformaUon stored in ^ ^ ^ occurrence of an 

the m^ed^pt storage means and disabling antnter- intmu £ t0 the CPU 13 and a main storLe 1 are connected 

iq» designated by the infonnaoon in order to perform ^ me J^, ^b^^ it b assum Jthat me ^S5 

exclusive control regarding processing in the real-tune oper- • , *" ;^,J~"vt^„ " ™~~rr ~r numo(r °* 

ating system, and intern^ enabling processing mcanste "21^^^ „ ^ ^ 'kIT** 

enabling the disabled interrupt 40 £°f^ 12 ( } 6) ^ d me mt f tru P t numbcR from 

T " . * ... 0 to 15 are allocated to the respective interrupt inputs. 

In *e present invention, from among interrupts which are Further, the interrupt controller 12 includes an taterrupt 

generated asynchronously, ^formation of only those which ^ ^ 30 for imerrupts individually for the 

issue a system call to the OS in a corresponding interrupt interrupt inputs, and when an input is received at one of 

handler is stored into the managed interrupt storage means 4J ttosc intent which „. not mad[eA by ^ ^tampl 

to manage those interrupts by the OS. Accordingly, any nmsk ^ 30 ^ intem,,,, controller 12 transmits occur- 

mterrupt which does not directly relate to operation of the rence of ^ interrupt to die CPU 13. A real-time OS 6 is 

OS such as an interrupt in whose corresponding interrupt residcnt in the main storage 1. and routines of tasks, routines 

handler no system call is issued is not influenced by the OS c f interrupt handlers are loaded into the main storage 1 

at all and consequently, processing relating to the interrupt x Further . managed interrupt storage means 9 for storing and 

can be performed without any delay. On the other hand, for interrupt numbers managed by the OS 6 is provided Within 

any interrupt in whose corresponding interrupt handler a the main storage 1. Here, an interrupt A from an interrupt 

system call to the OS is issued, the same operation as in factor 10 and another interrupt B from another interrupt 

conventional systems is secured. factor 11 are inputted to the interrupt controller 12. A routine 

The above and other objects, features and advantages of ss 3 of a task A and another routine 4 of another task B are 

the present invention will be apparent from the following loaded as routines of tasks in the main storage 1. and an 

description referring to the accompanying drawings which interrupt handler 4 started by the interrupt A and another 

illustrate examples of preferred embodiments of the present interrupt handler 5 started by the interrupt B are loaded as 

invention. interrupt handlers in the main storage 1. The managed 

BRIEF DESCRIPTION OF THE DRAWINGS 60 *?T T^/l* * S * SCOrage which 

is referred to by the OS 6. 

FIG. 1 is a block diagram showing the construction of a The OS 6 includes, in the inside thereof, interrupt dis- 

conventional computer system controlled by a typical real- abling processing means 7 for inhibiting an interrupt of a 

time particular interrupt number in order to perform exclusive 

FIG. 2 is a timing chart illustrating processing in the 65 control in system call processing, interrupt enabling pro- 
computer system shown in FIG. 1 when interrupts succes- cessing means 8 for putting the CPU 13 into an interrupt 
sively occur; enabling condition, and particular interrupt operation pro- 
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cessing means 14 for preventing acceptance by the CPU 13 that only an interrupt of the type I may not be accepted, 
of a particular one of interrupts disabled by the interrupt Consequently, any interrupt of the type L that is. the inter- 
disabling processing means 7. More particularly, the inter- rupt A by the interrupt factor 10, is inhibited. In mis instance, 
nipt disabling processing means 7 is a routine which is an interrupt of the type n is not disabled, 
called to disable an interrupt and reads out interrupt numbers 5 Here, it is assumed that the interrupt A (indicated as "INT 
from toe managed interrupt storage means * The interrupt fromthe interrupt factor 10 occurs at time 17 within the 
ena^gr^ssmgm^nsS^ . totiting period in the system call processing, 
the interrupt mask table 30 of the interrupt controller 12 via „~~V J~ TV * *^ eftKls " S eM 1„ i„t J™* a thl 
the CPU 13 and enables all interrupts. Meanwhile, the ?f e ' since f? 1 ^ " ^ > ? 
particular interrupt operation processing means 14 is a lfl J"* COnttoU f f h ^ ^^ C m "™** * Accordmgly 
. ■_ * * J; * * *u • . i * ui 10 the processing of the CPU 13 does not pass to the interrupt 
routine which performs writing into the interrupt mask table ^ S\ a 

30 of the interrupt controller 12 via the CPU 13 so that only han<Uer 

interrupts of interrupt numbers read out from the managed » is assumed that the interrupt B (indicated as "INT B") 

interrupt storage means 9 by the interrupt disabling process- from interrupt factor 11 is subsequently generated at time 

ing means 7 may be inhibited. 18 within toe interrupt disabling intervaL As described 

In the computer system of the present embodiment inter- above - mc interrupt B does not issue a system call in the 

rupts inputted to the system are classified into two types. corresponding interrupt handler 5 and is excepted from the 

These are type L interrupt which issues a system call to the * management by the OS 6 and accordingly is 

OS 6 in an interrupt handler corresponding to the interrupt enabled * Therefore, the interrupt B suspends the system call 

and type It interrupt which does not issue a system call in M processing without being influenced by the OS 6 and the 

an interrupt handler corresponding to the interrupt An interrupt handler 5 is started immediately, 

interrupt of the type I is an interrupt for which management After completion of the processing of the interrupt han- 

of enabling/disabling of the interrupt by the OS 6 is required. dler 5. the processing passes back to the suspended system 

and the corresponding interrupt number is stored into the processing, and an interrupt of the type I is enabled by 

managed interrupt storage means 9. On the other hand, an ^ the interrupt enabling processing means 8 at time 19. As a 

interrupt of the type n docs not issue a system call, and result, the interrupt A held formerly is accepted, and the 

accordingly, enabling/disabling of the interrupt is not per- processing is transferred to the interrupt handler 4. 

formed by the OS 6. The corresponding interrupt number is FIG. 6 is a flow chart illustrating processing when an 

not stored in the managed interrupt storage means 9. interrupt of the type I occurs. If an interrupt of the type I is 

Here, it is assumed that the interrupts of the interrupt 30 inputted, then the processing branches at step SI depending 

numbers 0 to 7 are of the type I and the interrupts of the upon whether the CPU 13 is in the interrupt enabling 

interrupt numbers 8 to 15 are of the type IL The interrupt condition (EI) or the interrupt disabling condition {DC). If the 

numbers 0 to 7 are stored in the managed interrupt storage CPU 13 is in the interrupt enabling condition, that is. the 

means 9. Further, it is assumed that the interrupt A from the interrupt is not masked at the interrupt mask table 30, then 

interrupt factor 10 is an interrupt of the type I whereas the 35 the processing passes to a corresponding interrupt handler 

interriipt B from me intemirM factor 11 is an internjpt of the (step S2). and then after the processing of the interrupt 

type IL Accordingly, the interrupt handler 4 issues a system handler comes to an end, the processing returns to the 

call in the inside of the routine thereof whereas the interrupt processing which has been executed prior to the interrupt 

handler 5 does not issue a system call. (step S3), thereby completing a series of processes. On the 

Now. the interrupt processing by the computer system is 40 °ther hand, if the CPU 13 is in the interrupt disabling 

described with reference to FIG. 5. Here, description is condition, that is. the interrupt is masked by the interrupt 

given of the case wherein a system call to the OS 6 is issued mask table 30, then the interrupt handler processing is held 

by the task A during execution of the task A and, within the until the interrupt enabling condition is entered again (step 

interrupt disabling interval in the system call processing, the S4). After the interrupt enabling condition is entered again, 

interrupt A is inputted to the interrupt controller 12 from the 45 mc processing advances to step S2 described above. After 

interrupt factor 10 and then the interrupt B is inputted to the similar processing to that performed using the conven- 

interrupt controller 12 from the interrupt factor 11. In FIG. tional interrupt managing method is performed. 

5, each thick line represents a routine being executed by the On the other hand, FIG. 7 is a flow chart illustrating 

CPU 13. Further. EI (enabling interrupt) represents an processing when an interrupt of the type n occurs. If an 

interrupt enabling interval, and DI (disabling interrupt) 50 interrupt of die type II is inputted, then branching of the 

represents an interrupt disabling interval. processing depending upon whether the CPU 13 is in the 

It is assumed that during execution of the routine 2 of the interrupt enabling condition (EI) or the interrupt disabling 

task A while the CPU 13 is in the interrupt enabling condition (DI) does not occur as seen from step S5. Then, in 

condition for all interrupts, a system call to the OS 6 is any case, the processing is transferred to a corresponding 

issued at time 15. As a result the processing by the CPU 13 55 interrupt handler at step S6. Then, after the processing of the 

is transferred from the task A into the OS 6. by which system interrupt handler comes to an end, the processing returns to 

call processing is performed. During the system call the processing which has been performed prior to the 

processing, since disabling of any interrupt must be per- interrupt (step S7), thereby completing a series of processes, 

formed within an interval within which exclusive control for After all, the interrupt processing is executed without being 

the resources is required, the interrupt disabling processing 60 influenced by the OS. 

means 7 is called at time 16. The interrupt disabling pro- In this manner, in the computer system which employs the 

cessing means 7 reads out the interrupt numbers stored in the interrupt managing method of the present embodiment 

managed interrupt storage means 9 and outputs the interrupt interrupt processing for which high emergency is required 

numbers thus read out as interrupts to be disabled to the can be executed immediately without being influenced by 

particular interrupt operation processing means 14. The 65 the OS if it does not issue a system call to the OS. 

particular interrupt operation processing means 14 operates Accordingly, a real-time OS can be implemented into fields 

the interrupt mask table 30 of the interrupt controller 12 so into which implementation is obstructed in conventional 
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processing because the interrupt disabling time by an OS is operation processing means 14 operates the interrupt mask 

long. Further, when it is required to issue a system call to the table 30 of the interrupt controller 12 based on the thus 

OS from within an interrupt handler, quite similar process- transferred interrupt number so that only the interrupt A is 

ing to conventional processing is performed, and disabled. 

consequently, the compatibility with conventional systems is 5 Here, it is assumed that the interrupt A (indicated as "INT 

maintained. A") from the interrupt factor 10 is inputted at time 37 within 

Second Embodiment ^ e inteiTU P t doling interval in the system call processing. 

Since the interrupt disabling for the interrupt A is set, the 

FIG. 8 shows a computer system to which a second interrupt controller 12 holds the interrupt A. Accordingly, 

embodiment of the present invention is applied. The com- 10 the processing of the CPU 13 does not is not transferred to 

puter system of the second embodiment is similar to the the interrupt handler 4. 

computer system of the first embodiment, but is different in Then, it is assumed that the timer interrupt C (indicated as 

that it includes a timer controller 20 which generates a timer "CLOCK IKT) is generated by the timer controller 20 at 

interrupt C in place of the interrupt factor which outputs the time 38 within the interrupt disabling interval. Since the 

interrupt B. and a timer interrupt handler 21 is prepared in 15 timer interrupt C is not placed under the management of the 

place of the interrupt handler 5 in the main storage 1 and OS 6 as a result of setting of the OS 6 upon initialization, the 

managed interrupt information reception means 22 is pro- timer interrupt C is enabled. Consequently, even when the 

yided in the OS 6. The timer interrupt handler 21 is an CPU 13 is within the interrupt disabling interval the system 

interrupt handler whose interrupt factor is the timer interrupt call processing is suspended by the timer interrupt C and the 

C from the timer controller 20, and does not issue a system 20 timer interrupt handler 21 is started immediately 

call to the OS 6 and exeortes interrupt processing for which After completion of the processing of the timer interrupt 

no delay is allowed Meanwhile, the managed interrupt handler 21, the proce< sing returns to the mterruoted svstem 

information reception means 22 receives information of an ^ processing, and at time 39, the interrupt A isenabled by 

interrupt to be managed by the OS 6 from an appUcation the interrupt enabling processing means 8. As a result, the 

program and stores a corresponding interrupt number into 25 interrupt A held precedently is accepted, and the processing 

the managed interrupt storage means 9. passes to the interrupt handler 4. 

Next the processing by the computer system is described FIG. 10 is a flow chart illustrating the processing when the 

with reference to FIG. 5. Here, it is assumed that the interrupt A occurs. When the interrupt A is inputted, the 

interrupt handler A corresponding to the interrupt A issues a M processing branches at step S8 depending upon whether the 

system calL condition of the CPU 13 is the interrupt enabling condition 

First, as setting of the OS 6 upon initialization, only the (EI) or the interrupt disabling condition (DI). If the condition 

interrupt A is set to be managed by the OS 6. This is because, of the CPU 13 is the interrupt enabling condition, that is. the 

in the application program, a system call to the OS 6 is interrupt A is not masked at the interrupt mask table 30. then 

issued only from within an interrupt handler 2 which is 35 the processing is transferred to the interrupt handler 4 (step 

started in response to the interrupt A. This setting can be S9). and after the processing of the interrupt handler 4 comes 

modified by the application program The OS 6 receives, to an end, the processing returns to the processing which has 

upon initialization, information to be stored into the man- been performed prior to the interrupt (step S10), thereby 

aged interrupt storage means 9 from the application program completing a series of processes. On the other hand, if the 

by the managed interrupt information reception means 22. m condition of the CPU 13 is the interrupt disabling condition. 

Here, the interrupt number corresponding to the interrupt A that is, the interrupt A is masked by the interrupt mask table 

is received and stored into the managed interrupt storage 30, the processing of the interrupt handler 4 is held until after 

mcans 9 - the interrupt enabling condition is entered (step Sll). After 

In the following, description is given of the case wherein, the interrupt enabling condition is entered, the processing is 

after registration into the managed interrupt storage means 9 45 transferred to step S9 described above. After all, processing 

is performed in this manner, a system call to the OS 6 is similar to mat performed using the conventional interrupt 

issued by the task A during execution of the task A. and the managing method is performed. 

interrupt A is inputted from the interrupt factor 10 to the Meanwhile, FIG. 11 is a flow chart illustrating the pro- 
interrupt controller 12 and then the timer interrupt C occurs cessing when the timer interrupt C is generated When the 
within the interrupt disabling interval in the system call 50 timer interrupt C is inputted, branching of the processing 
processing. depending upon whether the condition of the CPU 13 is the 
It is assumed mat the CPU 13 is in the interrupt enabling interrupt enabling condition (£1) or the interrupt disabling 
condition for all interrupts, and during execution of the condition (DI) does not occur as seen from step S12. In any 
routine 2 of the task A, a system call to the OS 6 is issued case, the processing is transferred to the timer interrupt 
at time 35. As a result, the processing by the CPU 13 is 55 handler 21 (step S13). and after the processing of the timer 
transferred into the OS 6. by which system call processing interrupt handler 21 comes to an end, the processing returns 
is performed. During the system call processing, since to that performed prior to the interrupt (step S14), thereby 
interrupt must be disabled within an interval within which completing a series of processes. After all, the timer inter- 
exclusive control of the resources is required, the interrupt rupt C is processed without being influenced by the OS. 
disabling processing means 7 is called at time 36. The 60 In the present embodiment a timer interrupt which has a 
interrupt disabling processing means 7 reads out the inter- high degree of urgency is processed without being infiu- 
rupt numbers stored in the managed interrupt storage means enced by the OS. For example, in a system which establishes 
9. Since only the interrupt number corresponding to the synchronism of communication based on docks produced 
interrupt A is stored in the managed interrupt storage means by the timer controller 20, clock interrupts at accurate 
9 as a result of setting of the OS 6 upon initialization, only 65 intervals are essentially required. Also to such a field that 
this interrupt number is transferred to the particular interrupt attaches importance to the accuracy in interrupt starting 
operation processing means 14. The particular interrupt interval time, introduction of a real-time OS can be achieved 
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by making use of the present embodiment Further, where 
there is the necessity to issue a system call to an OS from 
within an interrupt handler, operation quite similar to that 
performed by the conventional interrupt managing method 
can be performed, and accordingly, the compatibility with 5 
conventional systems is maintained. 

It is to be understood that variations and modifications of 
the interrupt managing system disclosed herein will be 
evident to those skilled in the art. It is intended that all such 
modifications and variations be included within the scope of 10 
the appended claims. 

What is claimed is: 

1. In a computer system which includes a CPU, wherein 
resources are managed by a real-time operating system and 
an asynchronous interrupt to the CPU may occur, an inter- 
rupt managing system for said computer, comprising: 15 

managed interrupt storage means in which information 
regarding interrupts to be managed by the real-time 
operating system is stored; interrupt disabling process- 
ing means for reading out the information stored in the 
managed interrupt storage means and disabling an 20 
interrupt designated by the information in order to 
perform exclusive control regarding processing in the 
real-time operating system; and 

interrupt enabling processing means for enabling the 
disabled interrupt. 25 

wherein interrupts that are not to be managed by the 
real-time operating system are not disabled by the 
interrupt disabling processing means, and are executed 
without delay by the CPU. 

2. The interrupt managing system according to claim 1. ^ 
further comprising: 

an interrupt controller connected to the CPU and having 
a plurality of individually maskable interrupt inputs for 
transmitting an interrupt to the CPU in response to an 
input to one of the maskable interrupt inputs which is 35 
not masked; and 

particular interrupt operation means for setting a mask to 
the interrupt controller corresponding to the interrupt 
disabled by the interrupt disabling processing means. 

3. In a computer system which includes a CPU, wherein 
resources are managed by a real-time operating system and 40 
an asynchronous interrupt to the CPU may occur, an inter- 
rupt managing system for said computer, comprising: 

managed interrupt storage means in which information 
regarding interrupts to be managed by the real-time 
operating system is stored; 4 

interrupt disabling processing means for reading out the 
information stored in the managed interrupt storage 
means and disabling an interrupt designated by the 
information in order to perform exclusive control 
regarding processing in the real-time operating system; 50 

interrupt enabling processing means for enabling the 
disabled interrupt; 

an interrupt controller connected to the CPU and having 
a plurality of individually maskable interrupts for trans- 
mitting an interrupt to the CPU in response to an input 55 
to one of the maskable interrupt inputs which is not 
masked; and 

particular interrupt operation means for setting a mask to 
the interrupt controller corresponding to the interrupt 
disabled by the interrupt disabling processing means. 60 

wherein only information regarding an interrupt in whose 
corresponding interrupt handler a system call to the 
real-time operating system is issued is stored in the 
managed interrupt storage means. 

4. The interrupt managing system according to claim 2, 65 
wherein the interrupt enabling processing means cancels a 
mask set to the interrupt controller. 
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5. The interrupt managing system according to claim 2, 
wherein the interrupt disabling processing means, the inter- 
rupt enabling processing means and the particular interrupt 
operation means are constructed as individual routines in the 
real-time operating system. 

6. In a computer system which includes a CPU. wherein 
resources are managed by a real-time operating system and 
an asynchronous interrupt to the CPU may occur, an inter- 
rupt managing system for said computer, comprising: 

managed interrupt storage means in which information 
regarding interrupts to be managed by the real-time 
operating system is stored; 

interrupt disabling processing means for reading out the 
information stored in the managed interrupt storage 
means and disabling an interrupt designated by the 
information in order to perform exclusive control 
regarding processing in the real-time operating system; 

interrupt enabling processing means for enabling the 
disabled interrupt; 

an interrupt controller connected to the CPU and having 
a plurality of individually maskable interrupts for trans- 
mitting an interrupt to the CPU in response to an input 
to one of the maskable interrupt inputs which is not 
masked; and 

particular interrupt operation means for setting a mask to 
the interrupt controller corresponding to the interrupt 
disabled by the interrupt disabling processing means, 

wherein a timer controller which generates a timer inter- 
rupt is connected to the interrupt controller, and infor- 
mation regarding the timer interrupt is not stored in the 
managed interrupt storage means. 

7. The interrupt managing system according to claim 6. 
wherein a system call to the real-time operating system is not 
issued in a timer interrupt handler corresponding to the timer 
interrupt 

8. In a computer system which includes a CPU. wherein 
resources are managed by a real-time operating system and 
an asynchronous interrupt to the CPU may occur, an inter- 
rupt managing system for said computer, comprising: 

managed interrupt storage means in which information 
regarding interrupts to be managed by the real-time 
operating system is stored; 

interrupt disabling processing means for reading out the 
information stored in the managed interrupt storage 
means and disabling an interrupt designated by the 
information in order to perform exclusive control 
regarding processing in the real-time operating system; 

interrupt enabling processing means for enabling the 
disabled interrupt; 

an interrupt controller connected to the CPU and having 
a plurality of individually maskable interrupts for trans- 
mitting an interrupt to the CPU in response to an input 
to one of the maskable interrupt inputs which is not 
masked; 

particular interrupt operation means for setting a mask to 
the interrupt controller corresponding to the interrupt 
disabled by the interrupt disabling processing means. 

managed interrupt information reception means for stor- 
ing managed interrupt information received from an 
application program into the managed interrupt storage 
means, the managed interrupt information reception 
means being constructed as an individual routine in the 
real-time operating systems 

wherein the interrupt disabling processing means, the 
interrupt enabling processing means and the particular 
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interrupt operation means are connected as individual 
routines in die real-time operating system. 
9. The interrupt managing system according to claim 8, 
wherein, upon initialization of the real-time operating 
system, the managed interrupt information reception means 
receives and stores the managed interrupt information into 
the managed interrupt storage means. 
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10. The interrupt managing system according to claim 1, 
wherein the interrupts that arc not disabled by the disabling 
processing means correspond to interrupts that do not issue 
a system call in a respective interrupt handler corresponding 
to the interrupts. 
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ADDING REAL-TIME SUPPORT TO 
GENERAL PURPOSE OPERATING SYSTEMS 

This application claims the benefit of U.S. provisional 
application Ser. No. 60/033,743 filed Dec. 23, 1996. 

BACKGROUND OF THE INVENTION 

This invention relates to real-time operating systems, and, 
more particularly, to running a real-time operating system 
with a general purpose operating system. 

General purpose computer operating systems "time- 
share" programs to optimize use of the machine or response 
time, or some other mix of objectives. Such programs cannot 
be used for control of instruments, robots, machine tools, 
communication devices, or other machinery that requires 
operation at "hard" real-time, i.e., precise timing where 
deadlines cannot be missed, because the systems are 
designed to optimize average performance of application 
programs at the expense of predictability. Performing the 
above tasks requires real-time support in the operating 
system: an ability to schedule tasks at precise intervals, no 
matter what other system tasks may be active. But real-time 
support can only be offered if the operating system can 
ensure (1) low interrupt latency (fast response) and (2) fully 
pre-emptive task switching. Low interrupt latency means 
that whenever a hardware device or the clock signals the 
processor, the operating system will execute a "handler" 
program within a short and bounded interval of time. Fully 
preemptive task switching means that whenever a high- 
priority real-time task is scheduled, it can be executed no 
matter what other tasks are currently executing. 

An exemplary need is a controller for an instrument that 
measures electrical discharges in thunderstorms. It is desir- 
able to read data from the instruments periodically, buffer 
and then write the data to disk, generate a graphical display 
of the data either locally or over the network, and possibly 
accept data from other instruments over the network. Only 
the first of these tasks requires hard real-time; the remainder 
are standard programming tasks for which a general purpose 
operating system is well suited. 

Another exemplary need is the control of a liquid fueled 
rocket mounted on a test platform. There is a need to sample 
and display data on numerous channels, update a remote 
real-time display, accept emergency shutdown commands, 
and perform routing control operations. Again, most of the 
requirements are for conventional operating systems 
services, but there are hard real -time components that need 
reasonably precise scheduling. For example, the shutdown 
sequence must be precisely timed and cannot be delayed by 
lower priority tasks without spectacular and unwelcome 
results. 

It is possible to design a special purpose operating system 
to support real-time, but this is an enormously complex, 
expensive and error-prone process that produces a system 
that needs a large continuing investment to remain current. 
In addition, there is substantial ongoing development effort 
and it is desirable to maintain compatibility with these 
developments, which are generally done by others. 

Accordingly, it is an object of the present invention to 
operate a real-time operating system, or executive, and 
retain the capabilities offered by a general purpose operating 
system. 

Additional objects, advantages and novel features of the 
invention will be set forth in part in the description which 
follows, and in part will become apparent to those skilled in 
the art upon examination of the following or may be learned 
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by practice of the invention. The objects and advantages of 
the invention may be realized and attained by means of the 
instrumentalities and combinations particularly pointed out 
in the appended claims. 

5 SUMMARY OF THE INVENTION 

To achieve the foregoing and other objects, and in accor- 
dance with the purposes of the present invention, as embod- 
ied and broadly described herein, this invention comprises a 

10 process for running a general purpose computer operating 
system using a real time operating system. A real time 
operating system is provided for running real time tasks. A 
general purpose operating system is provided as one of the 
real time tasks. The general purpose operating system is 

15 preempted as needed for the real time tasks. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in 
2Q and form a part of the specification, illustrate embodiments 
of the present invention and, together with the description, 
serve to explain the principles of the invention. In the 
drawings: 

FIG. 1A is a software flow diagram for the process of the 
25 present invention. 

FIG. IB is a software flow diagram for additional routines 
used in the flow diagram shown in FIG. 1A 

FIG. 2 is a software flow diagram for application of the 
present invention to the LINUX operating system. 
30 FIG. 3 is a continuation of the software flow diagram 
shown in FIG. 2. 

FIG. 4 is a continuation of the software flow diagram 
shown in FIG. 2. 

FIG. 5 is a continuation of the software flow diagram 
35 shown in FIG. 4. 

FIG. 6 is a continuation of the software flow diagram 
shown in FIG. 4. 

DETAILED DESCRIPTION 

40 

In accordance with the present invention, a real-time 
operating system, hereinafter called a RT-executive, runs a 
general purpose operating system as its lowest priority task, 
preempting it when needed. All operating systems have 

45 routines that enable and disable interrupts (or set interrupt 
levels). These routines are "captured" so that they pass 
through a small RT-executive and hardware emulator. 

Referring first to FIG. 1A, when the general purpose 
operating system attempts to disable hardware interrupts in 

50 accordance with the present invention, the emulator sets an 
indicator in software. When interrupts arrive 10, they are 
captured 12 by the RT-executive. The nature of the interrupt 
is then determined 14. If the interrupts cause a real-time task 
to be runnable, that task is started 16. If the interrupts are 

55 passed through to the general purpose operating system, the 
program determines if the software enable indicator is set 
18, If the software enable indicator is set, then an interrupt 
is emulated 22 and the handler in the general purpose 
operating system is run. A handler is a software routine that 

60 processes a particular system interrupt. If the enabled indi- 
cator is not set 24 (i.e., is cleared), a software pending 
interrupt indicator is set. As conventionally used herein, the 
term "soft" interrupt is used to mean interrupts that are 
emulated in software by the RT-executive; the term "hard" 

65 interrupt means interrupts generated by hardware. 

As seen in FIG. IB, when the general purpose operating 
system attempts to enable hardware interrupts 34, the 
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enabled indicator is set 36 and the pending indicator is One goal of this invention was to develop a Linux kernel 

checked 38. If an interrupt is pending, than an interrupt is that would support real-time control of scientific instru- 

emulated 42. If no software interrupts are pending, the ments. The limitations of standard time-shared operating 

request is returned 44. If the general purpose operating systems for this purpose include unpredictability of execu- 

system attempts to disable hardware interrupts 26, the 5 tion and high interrupt latency. General purpose time -shared 

enabled indicator is cleared 28 and the request is returned ope rating systems have schedulers that are intended to 

32. The result is that the real-time tasks are never disabled 5alance reS p 0 nse time and throughput. As a result, the 

from the executing, while the general purpose operating execution of any process depends m a lex and 

system requires only very minimal modifications. dksMt ^ h{oQ Qn load and ^ of ^ 

Hius, a form of emulator is the following routines, where 1Q processes . prob lems are compounded in Linux, and 

the general purpose operating system uses the routines mQSt Qther UN , X dedvati 5ecause kernd mode 

disable and enable to turn interrupts on and off, and also uses ... tll L1 . . 4 \ . 

a routine mask to selectively enable and disable interrupts tl0D , ls n°n-P«emptable and.because d.sabhng interrupts is 

/device* r used as the primary means of synchronization. 

Low interrupt handling latency is critical for any real-time 
15 operating system. But interrupt latency is high in Linux. On 

Soft_Enable 1: sets a flag indicating that soft interrupts are enabled a 120 MHz Pentium-based PC (Pentium is a trademark of 

SofUnable 2: sets a flag indicating that interrupts are enabled and Intel Corp.), Up to 400 //Sec latency has been measured for 

c * .v u, ^^^n^oUmtcnupts. handling "fast" Linux interrupts. It has been reported that the 

Soft_Disable: sets a flag indicating that soft interrupts are disabled T . ij- . c r . 

Soft_MaskOfF: passes a device or interrupt number, sets a flag to LmUX C0DS0 ? e dnver dlSableS interrupts for as long as 

disable soft interrupts from that device or interrupt 20 several milliseconds when switching virtual consoles, 

number Clearly, a frame-buffer that must be emptied every millisec- 

Soft„MaskOn passes a device or interrupt number, sets a flag to Qnd fe lhea be d tfae ^abilities of the system, and this 

enable soft interrupts from that device or interrupt 4 . . , • Al . , . 

number timing requirement is among the least demanding. 

LowteveiHandier (per hardware interrupt): The fundamental limits for real-time processing are deter- 

25 mined by the hardware. For example, a test system for 

If interrupt is handled by real time handler running the present system requires a time of approximately 

Then pass control to that handler - - _ . . . * „ , _f . , t / 

When the real-time handler, if any, completes operation 32 **** for settin g a blt on the P*™^ port. Obviously, this 

if interrupt is handled by soft handler or is shared does not support a requirement for a data rate of over 280 
and no realtime task if active KHz, regardless of the operating system. Similarly, the 
and soft interrupts are enabled 30 mm i ma i interrupt latency is bounded by the hardware inter- 
Then mark soft interrupts disabled and pass control to soft handler ~ n 

Else save interrupt information and set PendingFlag ^P 1 pfOCCSSUlg time. On a Pentium processor, at least 61 

cycles are needed to enter and exit the interrupt, and some 

__. . ... time is also needed for the interaction with the interrupt 

This routine works with minor modifications for systems controller Devices that need more id nse or more 

onand 1%°™°" lcvds otsim ^ turmn S irrupts 35 precise timing call for dedicated) or at least different) hard . 

t * . , . f ,i t . ware. But modem PC hardware is capable of handling the 

In a particular embodiment of the present invention as ... - . . r , • 

discussed below, the process is applied to the Linux oper- rea l; lime ^ ° f dcv \ < ?' . c 

ating system, a UNIX-derivative operating system that is The currenl version of RT - Linu * * * modification of 

publicly available from a variety of sources including L,nux 21 and 20 for Intel x86 based uni-processors and 

numerous internet sites. See, e.g., http://www.ssc.com/linux/ 40 multi-processors. Efforts are currently underway to move to 

resources/apps,html. As used herein, Linux interacts with a a 20 Linux kerael and to port the system to other processor 

software emulation of the interrupt control hardware. The architectures, including the IBM/Motorola PowerPC and 

emulation supports the synchronization requirements of the DEC Alpha. The test system has a 120 MHz Pentium 

Linux kernel while preventing Linux from disabling inter- processor, a 512 KB secondary cache and 32 MB of main 

rupts. Interrupts that are handled by Linux are passed 45 memory. All I/O devices, other than the video display and 

through to the emulation software after any needed real-time keyboard are DMA devices. Non-DMA controllers for mass 

processing completes. If Linux has requested that interrupts storage devices are difficult to integrate into a real- time 

be disabled, the emulation software simply marks the inter- control system. 

rupts as pending. When Linux requests that interrupts be A simple priority-based preemptive scheduler is currently 

enabled, the emulation software causes control to switch to 50 used in RT-Linux. It is implemented as a routine that chooses 

the Linux handler for the highest priority pending interrupt. among the ready proccss the highest-priority one and marks 

Linux is then able to provide sophisticated services to the it as a next process to execute Tasks give u the processor 

real-time system without increasing mterrupt latency voluntarily, or are preempted by a higher priority task when 

A virtual machine layer has been advanced as a technique iu time to execute comes 

for making UNIX real-time as far back as 1978 (H. Lyck- „ ^ . . . 4 , ~ , ^ t , . . . 4 

lama et a* "Unix time-sharing system: Hie MERToperat- 55 ^caMy, * * th( \ clock ,n f rU P t 

ing system," Bell System Technical Journal, 57(6) rate an ^ f h \ task rel ^ ase ^ en In most systems tasks are 

:2049-2086 (1978)). But the present system emulates only resumed in the ^ nod '° clock mterru P l handler ' Hl S h clock 

a specific hardware component— interrupt control. Linux is interrupt rate ensures low jitter, but, at the same time, incurs 

able to otherwise directly control the hardware both for much overhead - L<> w interrupt rate causes tasks to be 

run-time efficiency and in order to minimize the need for 60 resumed either too early or too late. In RT-Iinux this tradeoff 

modifications to the Linux kernel. The real-time executive ^ resolved by using a one-shot timer instead of a periodic 

that acts as the 0-level operating system does not provide clock. Tasks are resumed in the timer interrupt handler 

any basic services that can be provided by Linux. Instead, precisely when needed. 

the real-time executive is intended to provide services that Note that all task resources are statically defined. In 

Linux cannot provide. Thus, the real-time executive does not 65 particular, there is no support for dynamic memory alloca- 

provide network services or virtual memory or access to a lion. The basic approach is that any sophisticated services 

file system. that require dynamic memory allocation would be moved 
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into Linux processes. In keeping with this approach the timer variables, determines 72 whether a RT task needs to 

real-time kernel itself is not preemptable. run, and passes interrupts 74 to Linux only at appropriate 

Since the Linux kernel can be preempted by a real-time intervals, 

task at any moment, no Linux routine can safely be called If software interrupts are disabled, control simply returns 

from real-time tasks. However, some communication 5 78 through interrupt return (iret). Other wise, control is 

mechanism must be present. Simple FIFOs are used in pas sed 82 to the soft return from interrupt (S_IRET) 84. 

RT- Linux for moving information between Linux processes Macro 85 (FIG. 4) invokes the software handler correspond- 

or the Linux kernel and real-time processes. In a data- mg to tne interrupt that has the highest priority among 

collecting application, for example, a real-time process pending and not masked ones. 

would poll a device, and put the data into a FIFO. Linux 10 Tn e S_JRET code begins by saving minimal state and 
processes can then be used for reading the data from the making sure that the kernel data address space is accessible. 
FIFO and storing it in the file, or displaying it on the screen. i n the critical section surrounded by the actual cli and sti the 
Currently, interrupts are disabled when a RT-FIFO is software interrupt mask 82 is applied to the variable con- 
accessed. Since data are transmitted in small chunks, this taining pending interrupts, and then looks 84 for the highest- 
does not compromise a low response time. Other 35 priority pending interrupt. If there are no software interrupts 
approaches, notably using lock-free data structures, are also t o be processed, software interrupts are re-enabled 88 (FIG. 
possible. 5^ the registers are restored, and the system returns from the 
Modifications to the Linux kernel are primarily in three interrupt. If there is an interrupt to process 76 (FIG. 6), 
places: control is passed to its Linux "wrapper" 92. 

The cli routine to disable interrupts is modified to simply 2 o Each Linux "wrapper" has been modified to fix the stack 

clear a global variable controlling soft interrupt enable. so that it looks as if control has been passed directly from the 

The sti routine to enable interrupts is modified to generate hardware interrupt. This step is essential because Linux 

emulated interrupts for any pending soft interrupts. actually looks in the stack to see if the system was in user 

The low-level "wrapper" routines that save and restore or kernel mode when the interrupt occurred. If Linux 

state around calls to handlers have been changed to use 25 believes that the interrupt occurred in kernel mode, it will 

soft return from interrupt code instead of using the not call its own scheduler. The body of the wrapper has not 

machine instruction. been modified, but instead of terminating with an iret 

FIGS. 2-6 are flow diagram depictions of the process of operation, the modified wrapper invokes S_IRET. Thus, 

the present invention from which a person skilled in the art wrappers essentially invoke each other until there are no 

could form a suitable software routine for integrating a 30 pending interrupts left. 

real-time processor with a general purpose operating system. On re-enabling software interrupts, all pending ones, of 

Referring first to FIG. 2, when an interrupt occurs 50, course, should be processed. The code simulates a hardware 

control switches to a real-time handler. The handler does interrupt. The flags and the return address are pushed onto 

whatever needs to be done in the real-time executive 52; i.e., the stack and S__IRET is used. 

further interrupts are disabled, the interrupt status is saved, 35 Individual disabling/enabling of interrupts is handled 

and an acknowledgment (ACK) is issued. The ACK involves similarly. 

clearing the interrupt from the controller so that a later Thus, Linux has been modified as little as possible in 

HARD_ENABLE will not trigger a second interrupt from order to accommodate the real-time executive according to 

the same signal. But the ACK must not permit the device to the present invention. The real-time executive approach 

generate a second interrupt until it is hard-unmasked. Then 40 might be used as a basis for significant redesign of Linux and 

the nature of the interrupt is determined 54. If the soft similar operating systems. For example, device drivers often 

interrupt enable flag is set 56, then the stack is adjusted to have real-time constraints. If the real-time requirements of 

fit the needs of the Linux handler, hard interrupts are the drivers were made explicit and moved into the 

re-enabled and control is passed, via a soft interrupt table, to RT-kemel, then configuration programs could attempt to find 

the appropriate Linux "wrapper". The "wrapper" saves 45 a feasible schedule rather than allowing users to find out by 

additional state and calls the Linux handler 58 — a program experiment whether device time constraints are feasible. It 

usually written in C language. When the handler returns may also be possible to simplify design of the general 

control to the "wrapper" a soft return from interrupt is purpose kernel by giving the emulation a cleaner semantics 

executed 60. Soft return 60 from interrupt restores state and than the actual hardware. 

then checks to see if any other soft interrupts are pending. If 50 The foregoing description of the invention has been 

not, a hard return from interrupt is executed 62 so that hard presented for purposes of illustration and description and is 

interrupts are re-enabled along a short path whereby real not intended to be exhaustive or to limit the invention to the 

time interrupts can always be accepted. If there are interrupts precise form disclosed, and obviously many modifications 

pending 84 (FIG. 3), then the highest priority one is pro- and variations are possible in light of the above teaching, 

cessed. 55 The embodiments were chosen and described in order to 

Linux is reasonably easy to modify because, for the most best explain the principles of the invention and its practical 

part, the kernel code controls interrupt hardware through the application to thereby enable others skilled in the art to best 

routines cli() and siiQ. In standard x86 Linux, these routines utilize the invention in various embodiments and with 

are actually assembly language macros that generate the x86 various modifications as are suited to the particular use 

cli (clear interrupt bit) and sti (set interrupt bit) instructions 60 contemplated. It is intended that the scope of the invention 

for changing the processor control word. be defined by the claims appended hereto. 

As shown in FIG. 3, interrupt handlers 58 in the What is claimed is: 

RT-executive perform 66 whatever function is necessary for 1. A process for running a general purpose computer 

the selected RT system and then may pass 68 interrupts on operating system using a real time operating system, includ- 

to Linux. Since the real-time system is not involved in most 65 ing the steps of: 

I/O, most of the RT device interrupt handlers simply notify providing a real time operating system for running real 

Linux. On the other hand, the timer interrupt increments time tasks and components and non-real time tasks; 
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providing a general purpose operating system as one of 

the non-real time tasks; 
preempting the general purpose operating system as 

needed for the real time tasks; and 
preventing the general purpose operating system from 

blocking preemption of the non-real time tasks. 

2. A process according to claim 1, further including the 
step of providing a software emulator to disable and enable 
interrupts from the general purpose operating system. 

3. A process according to claim 2, wherein the software 
emulator performs the steps of: 

preventing the general purpose operating system from 
disabling hardware interrupts from hardware operating 
in real time; and 

emulating hardware interrupt control to preserve interrupt 
behavior expected by the general purpose operating 
system with only minimal changes to the general 
purpose operating system code. 

4. A process according to claim 3, further including the 
steps of allocating the hardware interrupts to either real-time 
tasks and components of the real-time operating system or to 
the general purpose operating system. 

5. A process according to claim 4, wherein allocating the 
hardware interrupts farther includes the steps of: 

passing control directly to real-time tasks or components 
when the hardware generates interrupts that are allo- 
cated to real-time tasks or to components of the real- 
time operating system; and 

passing control to the software emulator when the hard- 
ware generates interrupts that are allocated to the 
general purpose operating system. 

6. A process according to claim 2, further including the 
step of maintaining software interrupt control with the 
software emulator. 

7. A process for running a general purpose computer 
operating system using a real time operating system, includ- 
ing the steps of: 

providing a real time operating system for running real 

time tasks and components and non-real time tasks; 
providing a general purpose operating system as one of 

the non-real time tasks; 
preempting the general purpose operating system as 

needed for the real time tasks; 
preventing the general purpose operating system from 

blocking preemption of the non-real time tasks; 
providing a software emulator to disable and enable 

interrupts from the general purpose operating system; 
marking interrupts as "soft disabled" and not "soft 

enabled" in response to requests from the general 

purpose operating system to disable interrupts; 



15 



20 



25 



30 



35 



45 



50 



marking interrupts as "pending" and returning control to 
an interrupted thread of execution in response to hard- 
ware interrupts allocated to the general purpose oper- 
ating system if either the interrupted thread of execu- 
tion was a real-time task or component of the real-time 
operating system or if the interrupt has been marked as 
"soft disabled"; 

emulating the interrupt in response to hardware interrupts 
allocated to the general purpose operating system if 
both the interrupted thread of execution was not a 
real-time task or component of the real-time operating 
system and the interrupt has been marked as "soft 
enabled"; and 

marking interrupts as "soft enabled" and not "soft dis- 
abled" and then emulating any soft enabled interrupts 
in response to requests from the general purpose oper- 
ating system to enable interrupts. 

8. A process according to claim 7, wherein the software 
emulator performs the steps of: 

preventing the general purpose operating system from 
disabling hardware interrupts from hardware operating 
in real time; and 

emulating hardware interrupt control to preserve interrupt 
behavior expected by the general purpose operating 
system with only minimal changes to the general 
purpose operating system code. 

9. A process according to claim 8, further including the 
steps of allocating the hardware interrupts to either real-time 
tasks and components of the real-time operating system or to 
the general purpose operating system. 

10. A process according to claim 9, wherein allocating the 
hardware interrupts further includes the steps of: 

passing control directly to real-time tasks or components 
when the hardware generates interrupts that are allo- 
cated to real-time tasks or to components of the real- 
time operating system; and 

passing control to the software emulator when the hard- 
ware generates interrupts that are allocated to the 
general purpose operating system. 

11. A process according to claim 7, where the step for 
emulating the interrupt further consists of the steps of: 

marking the interrupt as "soft enabled" and not "soft 
disabled"; 

passing control to an appropriate interrupt handler of the 

general purpose operating system; and 
restoring state after the interrupt handler of the general 

purpose operating system completes the non-real time 

task. 
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ABSTRACT 



A method for the operation of a computer system controlled 
by a real-time operating system, which computer system 
processes interrupt signals. Upon the occurrence of an 
interrupt signal, the computer system interrupts a program 
that is to be processed at that time. The acceptance of further 
interrupt signals is blocked, and an interrupt routine belong- 
ing to this interrupt signal is called. During the processing of 
this interrupt routine, a first part of the program parameters 
of the program that is interrupted upon the occurrence of the 
interrupt signal is intermediately stored, and at least one 
datum concerning the interrupt signal is stored in an inter- 
rupt memory. A branching takes place from the interrupt 
routine to an interrupt management routine (IVR), whereby 
the acceptance of further interrupt signals is again cleared 
during the processing of the IVR. During the processing of 
the IVR, the datum belonging to the interrupt signal is 
erased; the remaining part of the program parameters of the 
program that is interrupted upon the occurrence of the 
interrupt signal is intermediately stored. Dependent on the 
datum concerning the interrupt signal, at least one reaction 
routine belonging to this interrupt signal is activated. After 
the processing of the IVR, the operating system branches 
back to the program that was interrupted upon the occur- 
rence of the interrupt signal, using the intermediately stored 
program parameters. 

19 Claims, 4 Drawing Sheets 
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METHOD FOR MANAGING INTERRUPT that was interrupted upon the occurrence of the interrupt 

SIGNALS IN A REAL-TIME COMPUTER signal, using the intermediately stored program parameters. 

SYSTEM The invention is based on the consideration that a short- 
ening of the interrupt blocking time contributes to the 

BACKGROUND OF THE INVENTION 5 capacily for processing the greatest possible number of 

The present invention relates to methods for operating a interrupt signals. The interrupt blocking time can be short- 
real-time computer system controlled by a real-time oper- ened wlleD previously necessary command sequences from 
ating system, which computer system processes interrupt an interrupt routine are transferred to external storage, which 
signals, e.g., of a technical process. sequences fall in the interrupt blocking time in known 

Methods of this type are used for example in real-time 10 methods - An interrupt management routine can be provided 

computer systems utilized in telecommunication modules of for reactl0n r ° utl L nes L belonging to the individual interrupt 

the public and private networks. A real-time computer routmes ' m wmch those actl0ns for ^ Posing of the 

system is characterized in that the processing of a program interr "P t Sl ^ al thatdo not absolutely have to be executed 

activated, for example, as a reaction to an interrupt signal immediately upon the occurrence of the interrupt signal are 

can be interrupted within a known limited time interval, in 15 respectively transferred to external storage from the associ- 

order to continue the processing of this program only when ated lntemral n**™*- act i°ns include e.g. the secur- 

higher-priority programs have been processed. During the in S. of som , e of the re S lster data of me microprocessor, the 

processing of a program in telecommunication modules, e.g. majority of the steps previously carried out in the interrupt 

up to about 50,000 interrupt signals can occur per second, „ routlne for c the reactl0n t0 th / ""errupt signal, and the 

which respectively require an interruption of a program to be 20 restonn « of ,he re 8 IS,er data of me microprocessor that did 

processed at that time and a reaction to the interrupt signal. n ° l have to be secured immediately upon the occurrence of 

, , , , the interrupt signal. 

Known real-time computer systems block the acceptance „»■■<■■• 

of further interrupt signals for a predetermined time interval, The register data of the microprocessor that must be 

called the interrupt blocking time, so that interrupt signals 25 secur f d immediately upon the occurrence of the interrupt 

coming in during this time interval are not taken into account ^gnal is referred to in the following descnpt.on of the first 

is processed, and information or instructions can be lost. The P arl of lhe P ro S ram P*""«tera (context I parameters) of the 

interrupt blocking time is required so that the microproces- P ro S ram that f in <f™P ted «P°" the occurrence of the 

sor can secure its registers, can react at least partly to the lnte ™P l ?*™ l > and can be > e £. the <=" °f the fla 8 

interrupt signal, and can again update its register in order to 30 K ^ 1 " of the microprocessor. The rest of the data to be 

be able to continue the interrupted program. The longer this Mcured are f emd t0 , 35 the remaimng part of the program 

interrupt blocking time is, all the more incoming interrupt Peelers (context II and III parameters) of the program 

signals go without being processed. An improved method that 15 " lterru P ted U P°" the occurrence of the interrupt 

for the operation of a real-time computer system, in which S1 g na • 

the interrupt blocking time is reduced, would be advanta- 35 since durin S or u P on the processing of the interrupt 

g eous management routine the acceptance of further interrupt 

signals is again cleared, the interrupt blocking time is 

SUMMARY OF THE INVENTION shortened considerably in contrast to known methods. 

An object of the invention is to develop a real-time Consequently, it is also the case that fewer interrupt signals 

operating system component that permits the acquisition of, 40 T thefeby l0St ' a ° d fewef dat / ! hat . are aVailable ° nly for a 

and reaction to, the highest possible number of occurring short time u P on occ ™™<* of the interrupt signal are lost, 

interrupt signals per time unit. ^ advantageous construction of the inventive method is 

To that end, in an embodiment, the invention provides the that the clearin S of the acce P tance ° f further interrupt signals 

following method steps: when an interrupt signal occurs, the ensues at the beginning of the interrupt management routine, 

real-time computer system interrupts a program processing 45 Due t0 a cleann § of the acce P tance of ^ther interrupt 

at that time; the acceptance of further interrupt signals is sl S nals that takes P lace as earl y P ossible > the interrupt 

blocked, and an interrupt routine belonging to this interrupt blocking time is determined only through an absolutely 

signal is called; during the processing of this interrupt necessary time interval, and is thus maximally shortened, 

routine, a first group of one or more program parameters of In a preferred embodiment of the invention, the storing of 

the program that was interrupted upon the occurrence of the 50 tne remainder part of the program parameters of the program 

interrupt signal is intermediately stored; at least one datum lnat is interrupted upon the occurrence of the interrupt signal 

concerning the interrupt signal is stored in an interrupt is intermediately stored, partly in a first stack memory for 

memory; a branching takes place from the interrupt routine program parameters (context II), which memory is allocated 

to an interrupt management routine, whereby the acceptance to tne interrupted program, and partly in a second stack 

of further interrupt signals is again cleared during the 55 memory for program parameters (context III), which 

processing of the interrupt management routine; during the memory is allocated to the interrupt management routine. In 

processing of the interrupt management routine, the datum lnis wav » memory space can be saved, since the program 

belonging to the interrupt signal in the interrupt memory is parameters stored in the second stack memory do not have 

erased; the remainder of the program parameters of the t0 be additionally stored for each interrupted program, 

program that was interrupted upon the occurrence of the 60 These and other features of the invention are discussed in 

interrupt signal are intermediately stored; depending on the greater detail below in the following detailed description of 

datum concerning the interrupt signal in the interrupt the presently preferred embodiments with reference to the 

memory, at least one reaction routine belonging to this accompanying drawings, 
interrupt signal is activated and, if warranted, is processed 

with activation of the real-time operating system; and after 65 BRIEF DESCRIPTION OF THE DRAWINGS 

the processing of the interrupt management routine, the FIG. 1 is a flow chart of method steps undertaken upon the 

real-time operating system branches back to the program occurrence of an interrupt signal. 
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FIGS. 2a, 2b and 2c constitute a flow chart of the method If it is determined in method step 18 that the content of the 

steps executed in the context of the processing of an inter- blocking counter deviates from its initial value, i.e. a non- 

rupt management routine. interruptible program routine is active, or if it is determined 

in method step 20 on the basis of the state memory cell that 

DETAILED DESCRIPTION OF THE 5 t he interrupt management routine has already been 

PRESENTLY PREFERRED EMBODIMENTS activated, a jump back to the interrupt routine ensues (step 

In the figures, the method steps in which the acceptance 24 )' In tne interrupt routine, context I is restored, by reading 

of interrupt signals is blocked are indicated by double the data for the processor registers out of the stack memory 

arrows. On the other hand, single arrows identify method a S akl ' in a seq ueoce that is the reverse of that in which they 

steps in which the acceptance of further interrupt signals is 30 were stored < ste P 26 >- Afterwards, there ensues the clearing 

cleared. °f tne acce ptance of further interrupt signals, and a return 

1 •« . . a L ^ c * c i j takes place to the program that was interrupted upon the 

FIG. 1 illustrates a flow chart of steps of a method c . . & 4 . . r r c iL 

... -i £ A . • 4 . i . . • j i occurrence or. the interrupt, in order to process it further 

embodying principles ot the invention which is undertaken , . 2 «\ 

upon the occurrence of an interrupt signal (step 10). Imme- '* 

diately after the occurrence of the interrupt signal, the 15 U P t0 the last method ste P 28 ' a11 method ste P s in FIG * 1 

acceptance of further interrupt signals is blocked by the arc carned out whlle the irrupt block is in effect, so that 

real-time computer system. So that the microprocessor can U P 10 thls P oint there results no essential adv antage over the 

continue the processing of the interrupted program at a later P nor art W1 f h res P ect to the interrupt blocking time. The 

time after the interruption by the interrupt signal, the state of savm S s 18 first visible on me basis of the method ste P s 

its registers must be stored before further steps for the 20 according to FIGS. 2«, 26, 2c, since in the method sequence 

processing of the current interrupt signal are carried out. As shown thcre the ma J ont y of the mcth <> d steps are carried out 

already stated, that part of the program parameters of the Wlth thc clearm S of the a ^ptance of further interrupt 

program interrupted upon the occurrence of the interrupt signals. 

signal that must be stored or saved immediately after the FIGS 2a > 2b > 2c show a flow chart of steps of an 
occurrence of the interrupt is designated context I param- interrupt management routine. After the interrupt manage- 
eters (even though it may be a single item). This saving ment routine has been called in method step 22, the micro - 
ensues while an interrupt block (step 12) is in effect, processor begins the processing of the method steps of the 
whereby the program parameters are stored in a stack interrupt management routine (step 40). 
memory in a predetermined sequence. 3Q Subsequently, the state memory cell is set (step 42). Upon 
After the microprocessor is again allowed to alter the the occurrence of further interrupt signals, it can thereby be 
register contents after the saving of the register data, it can determined in method step 20 whether the interrupt man- 
confirm the acceptance of the interrupt signal to other agement routine has already been activated, since in a 
components of the real-time computer system, such as e.g. correct execution of the method it may be activated only 
circuits for accepting interrupt (step 14). In known methods, 35 once - 

the method steps 12 and 14 are carried out within the In order to shorten the interrupt blocking time over known 

interrupt routine, and thus should also be regarded here as methods to the greatest possible extent, the acceptance of 

components of an interrupt routine. further interrupt signals is cleared at once (step 44). After 

So that the interrupt signal can be processed later, the method step 44 has been processed, it is thus possible to 

microprocessor stores a datum that points to the interrupt 40 accept and process further interrupt signals. These further 

signal in an interrupt memory (step 16). This interrupt interrupt signals are registered in the interrupt memory by 

memory can be e.g. a memory cell comprising several bits lne microprocessor as data in the form of set bits, in method 

combined into one memory word, in which a particular bit ste P 16 u P on the subsequent continuation of the processing 

is set according to the type of interrupt signal that occurs, so of tne method steps in the interrupt management routine, 

that it can be determined later which interrupt signal 45 tnese further interrupt signals can be taken into account, 

occurred. This possibility is described below. The program parameters of the program that was inter- 

The microprocessor subsequently checks whether, at the rupted upon the occurrence of the interrupt signal, which 

time of the occurrence of the interrupt signal, program parameters were not yet stored as context I in method step 

routines are being processed in the real-time computer 12 » are divided into two groups. One group is formed by 

system that are time-critical and thus may not be interrupted 50 program parameters that are intermediately saved or, 

(step 18). The number of such non-interruptible programs is respectively, intermediately stored in a stack memory for 

stored by the microprocessor in a memory cell, e.g. in a program parameters, which memory is allocated to the 

blocking (or block) counter with a determined initial value. interrupted program; this group of program parameters is 

The blocking counter is increased upon each calling of a designated or referred to herein as context II parameters. The 

non-interruptible program, and is correspondingly decreased 55 farther group of remaining program parameters is interme- 

after the processing of a non-interruptible program. In diately stored in a stack memory for program parameters, 

method step 18, the microprocessor can also determine allocated to the interrupt management routine, and is des- 

whether non-interruptible programs arc being processed at ignated or referred to as context III parameters, 

the current time. If this is not the case, i.e. if thc memory cell By means of this division of the remaining program 

of the blocking counter has the determined initial value, the 60 parameters, a considerable savings in memory space can be 

microprocessor checks whether an interrupt management achieved, since the context III parameter does not have to be 

routine (IVR) is already active, by querying a state memory respectively stored in the stack memory of the interrupted 

cell in which the state of the interrupt management routine program, but rather only in the stack memory of the interrupt 

is stored (step 20). If the interrupt management routine is not management routine. 

activated, it is called (step 22). The method steps to be 65 The saving of the context II parameters (step 46) ensues, 

executed within the interrupt management routine are as mentioned, in a stack memory allocated to the interrupted 

explained further below on the basis of FIGS. 2a, 2b and 2c. program. The stack memory of the interrupt management 
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routine is subsequently activated (step 48), and a saving of 
context III parameters ensues in this stack memory (step 50). 
A later continuation of the program that was interrupted 
upon the occurrence of the interrupt signal is possible by 
means of the storing of the program parameters. The reset- 5 
ting of the bit allocated to the interrupt signal in the interrupt 
memory, which was set upon the occurrence of the interrupt 
in method step 16, subsequently ensues in step 52. It is 
thereby possible that the same interrupt signal can be again 
accepted and evaluated that is being processed at that time 10 
by the interrupt management routine. 

After all preparations for the calling of a routine for the 
processing of the interrupt signal are concluded, the pro- 
cessing routine corresponding to the interrupt signal is called 
(step 54). During the execution of the processing routine, 15 
further interrupt signals can be accepted, which are then 
noted by the setting of corresponding bits in the interrupt 
memory in method step 16. After the execution of the 
processing routine in method step 54, the interrupt memory 
is queried for set bits by the microprocessor (step 56). If bits 20 
of this sort are set in the interrupt memory, the method is 
continued in method step 52. The method thereby finds itself 
in an operational loop formed by method steps 52 to 56. 
During the processing of the operational loop, further inter- 
rupt signals can be accepted that are signaled via the 25 
interrupt memory of the interrupt management routine, and 
are taken into account during the query in method step 56. 
Since, in contrast to known methods, the processing of the 
interrupt signals ensues with interrupt clearance, the inter- 
rupt blocking time can be considerably shortened. 30 

It is advantageous if the query for set bits in the interrupt 
memory in method step 56 takes into account the priorities 
of the accepted interrupt signals. In this way, the individual 
bits of the interrupt memory can be queried corresponding to 
an order of priority in the memory word of the interrupt 35 
memory, e.g. respectively from right to left, whereby a 
priority of the individual bits is determined that decreases 
from right to left in the memory word. 

The continuation of the method with the method steps of 4Q 
FIG. 2b does not ensue until all set bits in the interrupt 
memory have been reset (cf. method step 52) and the 
corresponding processing routines have been executed (cf. 
method step 54). The restoring of context III parameters 
(step 58) ensues by reading the program parameters of 45 
context III parameters out from the slack memory allocated 
to the interrupt management routine in the reverse sequence 
from that in which they were stored. 

There are two different possibilities for the calling of the 
interrupt management routine. The first possibility, already 50 
described, is the calling according to method step 22. In this 
case, the method steps 24 to 28 are not processed. As a 
second possibility, the interrupt management routine is 
called via the real-time operating system, if non- 
interruptible programs are being processed at the time of the 55 
occurrence of the interrupt signal, and the blocking counter 
was thereby already set in method step 18. The method steps 
24 to 28 would accordingly have already been executed 
before the calling of the interrupt management routine by the 
real-time operating system, as explained above, and thus 60 
may not be executed again within the interrupt management 
routine. 

The calling of the interrupt management routine via the 
real-time operating system can ensue in such a way that after 
the execution of a non-inlerruptible program and after the 65 
decrease in the blocking counter it is checked as to whether 
the blocking counter has the initial value, and whether at 



341 

6 

least one bit allocated to an interrupt signal is set in the 
interrupt memory. If both conditions are met, the interrupt 
management routine is called. 

In order to distinguish the two possibilities and to be able 
to process them correspondingly, a program stack memory 
allocated to a program management routine can be activated 
after the restoring of context III parameters in method step 
58, by loading the stack register of the microprocessor with 
the address of the stack memory of the interrupted program 
(step 60). The program management routine is a component 
of the real-time operating system, and coordinates the pro- 
cessing of programs by noting programs to be processed and 
starting their processing in a predetermined sequence. 

An increase in the blocking counter subsequently ensues 
(step 62), since the following method steps 64 and 66 may 
not be interrupted. Subsequently, the interrupt management 
routine is marked as inactive, e.g. by means of a setting of 
the state memory cell to zero (step 64), in order to enable the 
interrupt management routine to be processed again. 

A calling of the program management routine (step 66) 
then ensues, which if warranted brings another program to 
execution. After the termination thereof, the program man- 
agement routine causes a return to the interrupt management 
routine and a blocking of the acceptance of further interrupt 
signals (step 68). 

Since during the processing of method steps 56 to 68 
further interrupt signals could have been accepted, which 
signals have as a consequence the setting of allocated bits in 
method step 16 in the interrupt memory, during the process- 
ing of the interrupt management routine, before the termi- 
nation thereof, it is again queried whether bits are still set in 
the interrupt memory (step 70). If this is the case, the 
interrupt management routine is not terminated, but rather is 
set active again using the corresponding state memory cell 
(step 72), and the acceptance of further interrupt signals is 
again cleared (step 74). The method is subsequently contin- 
ued in method step 48. The interrupt management routine is 
now in a further operational loop consisting of method steps 
48 to 74. This further operational loop can be terminated 
only in method step 70, if all bits in the interrupt memory 
have already been reset. In this case, there ensues a resetting 
of the blocking counter via a corresponding lowering of its 
value (step 76). 

There subsequently ensues a restoring of context II (step 
78), in that a switchover takes place to the stack memory of 
the program that was interrupted upon the occurrence of the 
interrupt signal, and the program parameters stored there are 
read again in a sequence that is the reverse of that in which 
they were stored. 

The return to the interrupt routine ensues in step 80, in 
which context I is then restored (step 82). Subsequently, a 
return takes place to the program that was interrupted upon 
the occurrence of the interrupt signal (step 84). The interrupt 
management routine is thereby concluded. 

Although modifications and changes may be suggested by 
those skilled in the art, it is the intention of the inventors to 
embody within the patent warranted hereon all changes and 
modifications as reasonably and properly come within the 
scope of their contribution to the art. 

We claim: 

1. A method for operating a real-time computer system 
controlled by a real-time operating system, which computer 
system processes interrupt signals, comprising the following 
steps: 

when an interrupt signal occurs, the real-time computer 
system interrupts any program processing at that time; 
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the acceptance of further interrupt signals is blocked, and 
an interrupt routine for this interrupt signal is executed; 

during the processing of the interrupt routine, a first group 
of program parameters of the program interrupted upon 
the occurrence of the interrupt signal is intermediately 5 
stored; 

at least one datum concerning the interrupt signal is stored 
in an interrupt memory, branching to an interrupt 
management routine depending upon whether at least 
one program routine, which may not be interrupted, is 10 
being processed in the computer system; 

whereby the acceptance of further interrupt signals is 
again cleared during the processing of the interrupt 
management routine; 

during the processing of the interrupt management 
routine, the datum belonging to the interrupt signal in 
the interrupt memory is erased, 

the remainder of the program parameters of the program 
that was interrupted upon an occurrence of the interrupt 2 o 
signal are intermediately stored; 

depending on the datum of the interrupt signal in the 
interrupt memory, at least one reaction routine belong- 
ing to this interrupt signal is activated and, if warranted, 
is processed with activation of the real-time operating 25 
system; 

after the processing of the interrupt management routine, 
the real-time operating system branches back to the 
program that was interrupted upon the occurrence of 
the interrupt signal, using the intermediately stored 30 
program parameters. 

2. The method according to claim 1, characterized in that 
the clearing of the acceptance of further interrupt signals 
ensues at the beginning of the interrupt management routine. 

3. The method according to any of claims 1 and 2, 35 
characterized in that the first group of the program param- 
eters comprises the content of processor registers at the time 

of the interruption of a microprocessor controlled by the 
real-time operating system. 

4. The method according to any of claims 1 and 2, 40 
characterized in that the remainder of the program param- 
eters that remains during the processing of the interrupt 
management routine contains information concerning the 
state of the program that is halted upon the occurrence of the 
interrupt signal, and information that must be restored for 45 
the later continuation of the interrupted program. 

5. The method according to claim 1, characterized in that 
the storing of the remainder of the program parameters of the 
program that is interrupted upon the occurrence of the 
interrupt signal are intermediately stored partly in a first 50 
stack memory for program parameters, which memory is 
allocated to the interrupted program, and partly in a second 
stack memory for program parameters, which memory is 
allocated to the interrupt management routine. 

6. The method according to claim 1, characterized in that 55 
given several interrupt signals that follow upon one another, 
data belonging to these interrupt signals are stored in the 
interrupt memory. 

7. The method according to claim 6, characterized in that 
the data concerning accepted interrupt signals are stored 60 
according to a predetermined order of priority, and in that 
the processing of the interrupt signals ensues by means of 
the interrupt management routine, dependent on this order of 
priority. 

8. The method according to claim 1, characterized in that 65 
during the processing of the interrupt management routine, 
further data concerning interrupt signals are stored in the 
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interrupt memory, which data occur during the processing of 
the interrupt management routine, and in that the interrupt 
management routine is not terminated until no data concern- 
ing interrupt signals are stored in the interrupt memory. 

9. A method for operating a real-time computer system 
controlled by a real-time operating system, which computer 
system processes interrupt signals, comprising the following 
steps: 

when an interrupt signal occurs, the real-time computer 
system interrupts any program processing at that time; 

the acceptance of further interrupt signals is blocked, and 
an interrupt routine for this interrupt signal is executed, 

during the processing of the interrupt routine, a first group 
of program parameters of the program interrupted upon 
the occurrence of the interrupt signal is intermediately 
stored; 

at least one datum concerning the interrupt signal is stored 
in an interrupt memory, branching to the interrupt 
routine ensuing dependent on the value of a blocking 
counter that counts the calls of non-interruptible rou- 
tines of the real-time operating system; 

the interrupt routine is temporarily halted and an interrupt 
management routine is executed, whereby the accep- 
tance of further interrupt signals is again cleared during 
the processing of the interrupt management routine, 

the clearing of the acceptance of further interrupt signals 
ensuing at the beginning of the interrupt management 
routine; 

during the processing of the interrupt management 
routine, the datum belonging to the interrupt signal in 
the interrupt memory is erased; 

the remainder of the program parameters of the program 
that was interrupted upon an occurrence of the interrupt 
signal are intermediately stored; 

depending on the datum of the interrupt signal in the 
interrupt memory, at least one reaction routine belong- 
ing to this interrupt signal is activated and, if warranted, 
is processed with activation of the real-time operating 
system; and 

after the processing of the interrupt management routine, 
the real-time operating system branches back to the 
program that was interrupted upon the occurrence of 
the interrupt signal, using the intermediately stored 
program parameters. 

10. The method according to claim 9, characterized in that 
upon each calling of a non-interruptible routine the value of 
the blocking counter is increased, and after the processing of 
a non-interruptible routine the value of the blocking counter 
is correspondingly lowered. 

11. The method according to claim 9 or 10, characterized 
in that, using the intermediately stored program parameters, 
before the interrupt routine is processed the real-time oper- 
ating system branches back to the program that was inter- 
rupted upon the occurrence of the interrupt signal, if the 
blocking counter does not have a predetermined initial value 
or the interrupt management routine has not yet been fully 
processed. 

12. The method according to one of claims 9 or 10, 
characterized in that the branching to the interrupt manage- 
ment routine ensues when the blocking counter has the 
predetermined initial value, and at least one datum concern- 
ing an interrupt signal is stored in the interrupt memory. 

13. The method according to one of claims 5 to 8 or 10, 
characterized in that a restoring of the program parameters 
intermediately stored on the second stack memory allocated 
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to the interrupt management routine does not ensue until no 
datum is stored in the interrupt memory. 

14. The method according to one of claims 5 to 8 or 10, 
characterized in that a restoring of the program parameters 
intermediately stored on the first stack memory allocated to 5 
the interrupted program does not ensue until no datum is 
stored in the interrupt memory. 

15. A method for operating a real-time computer system 
controlled by a real-time operating system, which computer 
system processes interrupt signals, comprising the following 10 
steps: 

when an interrupt signal occurs, the real-time computer 
system interrupts any program processing at that time; 

the acceptance of further interrupt signals is blocked, and 
an interrupt routine for this interrupt signal is executed; 15 

during the processing of the interrupt routine, a first group 
of program parameters of the program interrupted upon 
the occurrence of the interrupt signal is intermediately 
stored; 2{) 

at least one datum concerning the interrupt signal is stored 
in an interrupt memory, branching to an interrupt 
management routine depending upon whether at least 
one program routine, which may not be interrupted, is 
being processed in the computer system; 2 5 

whereby the acceptance of further interrupt signals is 
again cleared during the processing of the interrupt 
management routine, 

the clearing of the acceptance of further interrupt signals 
ensuing at the beginning of the interrupt management 30 
routine; 

during the processing of the interrupt management 
routine, the datum belonging to the interrupt signal in 
the interrupt memory is erased; 

the remainder of the program parameters of the program 
that was interrupted upon an occurrence of the interrupt 
signal are intermediately stored; 

depending on the datum of the interrupt signal in the 
interrupt memory, at least one reaction routine belong- 40 
ing to this interrupt signal is activated and, if warranted, 
is processed with activation of the real-time operating 
system; 

after the processing of the interrupt management routine, 
the real-time operating system branches back to the 45 
program that was interrupted upon the occurrence of 
the interrupt signal, using the intermediately stored 
program parameters; and 

given several interrupt signals that follow upon one 
another, data belonging to these interrupt signals are 50 
stored in the interrupt memory. 

16. A method for operating a real-time computer system 
controlled by a real-time operating system, which computer 
system processes interrupt signals, comprising the following 
steps: 55 

when an interrupt signal occurs, the real-time computer 
system interrupts any program processing at that time; 

the acceptance of further interrupt signals is blocked, and 
an interrupt routine for this interrupt signal is executed; 6Q 

during the processing of the interrupt routine, a first group 
of program parameters of the program interrupted upon 
the occurrence of the interrupt signal is intermediately 
stored; 

at least one datum concerning the interrupt signal is stored 65 
in an interrupt memory, branching to an interrupt 
management routine depending upon whether at least 
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one program routine, which may not be interrupted, is 

being processed in the computer system; 
whereby the acceptance of further interrupt signals is 

again cleared during the processing of the interrupt 

management routine, 
the clearing of the acceptance of further interrupt signals 

ensuing at the beginning of the interrupt management 

routine; 

during the processing of the interrupt management 
routine, the datum belonging to the interrupt signal in 
the interrupt memory is erased; 

the remainder of the program parameters of the program 
that was interrupted upon an occurrence of the interrupt 
signal are intermediately stored; 

depending on the datum of the interrupt signal in the 
interrupt memory, at least one reaction routine belong- 
ing to this interrupt signal is activated and, if warranted, 
is processed with activation of the real-time operating 
system, the interrupt management routine not being 
terminated until no datum concerning an interrupt 
signal is stored in the interrupt memory; 

during the processing of the interrupt management 
routine, further data concerning interrupt signals are 
stored in the interrupt memory, which data occur during 
the processing of the interrupt management routine; 
and 

after the processing of the interrupt management routine, 
the real-time operating system branches back to the 
program that was interrupted upon the occurrence of 
the interrupt signal, using the intermediately stored 
program parameters. 
17, A method for operating a real-time computer system 
controlled by a real-time operating system, which computer 
system processes interrupt signals, comprising the following 
steps: 

when an interrupt signal occurs, the real-time computer 
system interrupts any program processing at that time; 

the acceptance of further interrupt signals is blocked, and 
an interrupt routine for this interrupt signal is executed; 

during the processing of the interrupt routine, a first group 
of program parameters of the program interrupted upon 
the occurrence of the interrupt signal is intermediately 
stored; 

at least one datum concerning the interrupt signal is stored 
in an interrupt memory, branching to an interrupt 
management routine depending upon whether at least 
one program routine, which may not be interrupted, is 
being processed in the computer system; 

whereby the acceptance of further interrupt signals is 
again cleared during the processing of the interrupt 
management routine, 

the clearing of the acceptance of further interrupt signals 
ensuing at the beginning of the interrupt management 
routine; 

during the processing of the interrupt management 
routine, the datum belonging to the interrupt signal in 
the interrupt memory is erased; 

the remainder of the program parameters of the program 
that was interrupted upon an occurrence of the interrupt 
signal are intermediately stored, the remainder of the 
program parameters of the program that is interrupted 
upon the occurrence of the interrupt signal being inter- 
mediately stored partly in a first stack memory for 
program parameters, which memory is allocated to the 
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interrupted program, and partly in a second stack 
memory for program parameters, which memory is 
allocated to the interrupt management routine; 
depending on the datum of the interrupt signal in the 
interrupt memory, at least one reaction routine belong- 
ing to this interrupt signal is activated and, if warranted, 
is processed with activation of the real-time operating 
system; and 

after the processing of the interrupt management routine, 
the real-time operating system branches back to the 
program that was interrupted upon the occurrence of 
the interrupt signal, using the intermediately stored 
program parameters. 
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18. The method according to claim 17, characterized in 
that a restoring of the program parameters intermediately 
stored on the second stack memory allocated to the interrupt 
management routine does not ensue until no datum is stored 
in the interrupt memory. 

19. The method according to claim 17, characterized in 
that a restoring of the program parameters intermediately 
stored on the first stack memory allocated to the interrupted 
program does not ensue until no datum is stored in the 
interrupt memory. 
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ABSTRACT 



A hardware -implemented interrupt handler external to a 
processor handles interrupts destined for the processor. The 
interrupt handler has a programmable prioritized interrupt 
array with programmable registers that identify priority 
levels and handling processes for handling one or more 
interrupts. The interrupt handler also has an interrupt scan- 
ning state machine that scans the prioritized interrupt fol- 
lowing receipt of an interrupt to extract the priority level and 
handling process associated with the interrupt. The interrupt 
handler is designed to handle interrupts in significantly less 
time than software implementations, thereby making the 
handler favorable for real time systems. 
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INTERRUPT HANDLER WITH 
PRIORITIZED INTERRUPT VECTOR 
GENERATOR 

TECHNICAL FIELD 

This invention relates to interrupt handlers and methods 
for handling interrupts. More particularly, this invention 
relates to interrupt handlers with prioritized interrupt vector 
generators that enable configuration of interrupt type and 
priority among the interrupts. 

BACKGROUND 

An "interrupt" is a request-for-attention signal that is 
passed to a computer's CPU (central processing unit) from 
hardware or software sources in an attempt to gain the 
CPU's attention. Interrupts can occur for many reasons, 
ranging from normal to highly abnormal situations, includ- 
ing service requests from hardware, errors in processing, 
program attempts to do the impossible, and memory prob- 
lems. A hardware interrupt is a request for service generated 
by hardware components, such as a keyboard, mouse, disk 
drive, I/O port, and microprocessor. 

The interrupt causes the CPU to suspend its current 
operations, save the status of its work, and transfer control 
to a process for handling the interrupt. Interrupt handlers are 
commonly implemented in software and more particularly, 
in a hardware abstraction layer. The interrupt handler typi- 
cally resides in the CPU at a known address. When an 
interrupt occurs, the CPU begins executing code at that 
location. The interrupt handler determines the cause of the 
interrupt and then services it by calling an appropriate set of 
instructions to be carried out. 

The interrupt handler initiates different instructions for 
different types of interrupts. More specifically, each type of 
interrupt has an associated dedicated routine, known as an 
"interrupt service routine" or "ISR". When a CPU receives 
interrupt requests from more than one source, the interrupt 
handler invokes a hierarchy of permission levels, called 
"interrupt priorities", to determine which of the interrupts is 
handled first. 

Conventional software-based interrupt handlers have a 
drawback in that the speed and performance is often unac- 
ceptable in real-time operating systems that are required to 
execute interrupts at very high speed and efficiency. The 
performance factor is further complicated by the desire to 
handle prioritized sets of interrupts from many diverse 
hardware platforms. Different hardware platforms often 
have different interrupts and dissimilar interrupt priorities. 
To be acceptable, an interrupt handler should provide real- 
time response for hardware interrupts and dynamic setting of 
interrupt priorities. 

One prior art interrupt handler that addresses these issues 
is described in U.S. Pat. No. 5,594,905, entitled "Exception 
Handler and Method for Handling Interrupts", which issued 
Jan. 14, 1997 in the name of Amit Mital, and is assigned to 
Microsoft Corporation. 

While this interrupt handler proved effective, the inven- 
tors sought to develop an even faster, hardware-based inter- 
rupt handler that minimizes software overhead to thereby 
improve performance. 

SUMMARY 

This invention concerns an interrupt handler implemented 
in hardware and external to a processor to handle interrupts 
destined for the processor. The interrupt handler has a 
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programmable prioritized interrupt array with program- 
mable registers that identify priority levels and handling 
processes for handling one or more interrupts. The interrupt 
handler also has an interrupt scanning state machine that 

5 scans the prioritized interrupt array following receipt of an 
interrupt to extract the priority level and handling process 
associated with the interrupt. The interrupt handler is 
designed to handle interrupts in significantly less time than 
software implementations, thereby making the handler 

10 favorable for real time systems. 

According to one implementation, the prioritized interrupt 
array has three registers that coordinate data associated with 
the interrupts received by the interrupt handler. A mask 
register holds mask values for corresponding interrupts that 

15 indicate whether the interrupts are enabled. Apriority reg- 
ister holds priority levels for the various interrupts, whereby 
two or more interrupts may be assigned the same priority 
level. An address register holds information for servicing the 
interrupts, such as addresses for interrupt service routines. 

20 The priority register and address register are programmable 
to enable a user to change the priority levels and servicing 
information for any given interrupt source. 

The interrupt scanning state machine operates on the 
prioritized interrupt array using a three -state process that 

25 includes an idle state, a scanning state, and an interrupt 
selected state. The state machine remains in the idle state 
until the prioritized interrupt array receives one or more 
active interrupts that are indicated by the mask register as 
being enabled. When one or more active interrupts are 

30 received, the interrupt scanning state machine transitions to 
the scanning state to scan the priority register and identify 
which of the one or more active interrupts has the highest 
priority. When the interrupt with the highest priority is 
found, the interrupt scanning state machine transitions to the 

35 interrupt selected state and accesses the address register to 
output information for handling the active interrupt with the 
highest priority. 

The interrupt handler is designed to be extendable. As an 
4Q example, two or more handlers can be connected in a 
cascading arrangement where the output of one interrupt 
handler supplies its highest priority interrupt as one of the 
many interrupts to another interrupt handler. 

BRIEF DESCRIPTION OF THE DRAWINGS 

45 

The same -reference numbers are used throughout the 
disclosure to reference like components and features. 

FIG. 1 is a block diagram of a modular computer system 
with two interrupt handlers arranged in a cascaded relation- 
50 ship. 

FIG. 2 is a block diagram of an interrupt handler. 
FIG. 3 a state diagram implemented by the interrupt 
handler. 

55 FIG. 4 is a flow diagram illustrating the process of 
handing an interrupt via the cascaded interrupt handlers. 

CONCLUSION 

Exemplary System 

60 FIG. 1 shows a computer system 20 having a CPU 
(central processing unit) module 22 and at least one support 
module 24. A bus structure 26 (e.g., PCI bus) interconnects 
the CPU module 22 and the support module 24. The CPU 
module 22 has a microprocessor 30 and an interrupt handler 

65 32 for handling interrupts or exceptions destined for the 
microprocessor. The interrupt handler 32 is constructed in 
hardware external to the microprocessor 30. 
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The interrupt handler 32 receives one or more interrupts rupts Int0-Int31, from various sources that provide inter- 

from different sources, evaluates the priorities of the rupts to the microprocessor 30. 

interrupts, and derives servicing information for the highest jhe prioritized interrupt array 40 is partitioned into a 

priority interrupt. The interrupt handler 32 passes the ser- m ask reg istcr 44 and a priority/address register 46. The 

vicing information and interrupt source number to the 5 registers each have N slots or entries that arc associated 

microprocessor 30 for servicing. The interrupt handler 32 within one another via the physical hardware structure. The 

implements a prioritized interrupt vector generator that m ask register 44 is an NxA register having one entry for 

enables the user to program the interrupt priorities and each associated interrupt source 42. Each entry holds a mask 

servicing information as desired. va i ue that indicates whether the associated interrupt is 

The CPU module 22, by itself, is generally representative 10 enabled. In one exemplary implementation, the mask regis- 

of an embedded processor device. Aspects of this invention ter 42 is a 32xl-bit register (i.e., N=32 and A=l) whereby 

are directed to the interrupt handler and to embedded each interrupt source is allotted an an associated mask bit, 

processor devices that incorporate the interrupt handler. represented by values mask0-mask31. The mask bit is active 

In addition, aspects of this invention concern the entire ( ie > a binary "1") if the interrupt is enabled and inactive 

computer system 20, whereby multiple interrupt handlers 15 (i- e > a binary "0") if the interrupt is disabled, 

are arranged in a cascaded architecture. For instance, in the The priority/address register 46 is an Nx(B+C) register 

illustrated example, the support module 24 has an interrupt having one entry for each associated interrupt source 42 and 

handler 34 that handles its own interrupts, evaluates the each corresponding entry in the mask register 44. Each entry 

priorities of the interrupts, and passes its highest priority in the priority/address register 46 contains a B-bit priority 

interrupt to the CPU-based interrupt handler 32. In the 20 field 48 that holds a priority level of the associated interrupt 

illustrated example, the CPU-based interrupt handler 32 42 and a C-bit address field 50 that holds servicing infor- 

receives the interrupt from the remote interrupt handler 34 as mation to servicing the associated interrupt, 

one of many interrupts (e.g., Int9). The CPU-based interrupt i n the exemplary implementation, the priority field 48 

handler 32 then evaluates the interrupt according to its own holds a five bit value (i.e., B=5) ranging from PriO (highest 

priorities. In this manner, the interrupt handler architecture 25 priority) to Pri31 (lowest priority) for each of the interrupt 

is extensible to multiple interrupt handlers, thereby enabling sources. Different interrupt sources may be assigned the 

the architecture to quickly handle large numbers of inter- S ame priority level. For example, interrupts Int3, Int4, and 

rupts* Int5 all have a priority Pri4. The address field 50 holds a 

The computer system 20 is representative of many dif- 3Q 32-bit address (i.e., C«32) that specifies a start address for 

ferent computing systems, including general -purpose com- an interrupt service routine (ISR) that can be invoked to 

puters and dedicated computing devices. As one particular service the associated interrupt. 

example, computer system 20 can be implemented as a h i s noted that the prioritized interrupt array 40 is expand- 

modular vehicle computer as described in U.S. Pat. No. able to have more or less than N slots and the bit sizes of the 

5,794,164, entitled "Vehicle Computer System", which 35 registers may vary depending upon the desired implemen- 

issued Aug. 11, 1998, in the names of Richard D. Beckert, tation. Furthermore, the priority/address register 46 may 

Mark Moeller, and William Wong and is assigned to hold values other than ISR addresses. For instance, in the 

Microsoft Corporation. The vehicle computer has three cascaded architecture described below, the address field 50 

modules— a computer module, a support module, and a m the CPU-based interrupt handler 32 may hold an address 

faceplate module— two of which are shown. The computer 4Q received from the remote interrupt handler 34 on the support 

module mounts in the vehicle dashboard or other location module 24 which is the highest priority interrupt from the 

and runs an operating system to support vehicle-related remote interrupt handler 34. 

applications and provide additional functionality typically ^ interrupt handler 32 also has an interrupt scanning 

afforded by a personal computer. The support module state machine 60 that scans the prioritized interrupt array 40 

contains, for example, a storage drive (which also functions 45 for aI1 active interrupt More particularly, when the 

as an entertainment player), power supply, a communica- interrupt handler 32 receives one or more of the interrupts 

hons bus, an AM/FM tuner, a DSP audio processor and a that are specified by the mask register 44 as being enabled, 

CODEC. The faceplate module (not shown) includes a an 0R gate 62 produces an interrupt active signal «, 

display, a keypad and an IrDA interface. The drivers for all active » that starts the state machine 60 . The 

hardware components run in the host microprocessor 30. 5Q ^ ming state machine scans the priority field 48 of the 

In the context of the vehicle computer, the remote inter- priority/address register 46 using mutiplexer 64 to discern 

nipt handler 34 handles interrupts from the components what priority levels are associated with the active interrupts, 

supported by the support module 24, such as the storage Upon locating an active interrupt and its associated priority 

drive and DSP audio processor. The CPU-based interrupt level, the state machine continues scanning for other active 

handler 32 handles interrupts directed toward the computer 55 interrupts to see if there is still a higher interrupt pending. If 

processor on the CPU module 22, such as interrupts from two or more active interrupts have the same priority, the 

software and hardware sources as well as interrupts received state machine will process the first interrupt source encoun- 

from the remote interrupt handler 34 on the support module tered in its scanning. 

Upon determining the highest-priority active interrupt 

Interrupt Handler 60 source to be serviced, the state machine 60 asserts three 

FIG. 2 shows the interrupt handler 32 in more detail. signals: (1) a "Irq_selected" signal indicating that a certain 

Interrupt handler 34 is constructed in a similar manner, and interrupt has been selected; (2) a "Highest_Irq" signal 

thus only one handler is described. The interrupt handler indicating that the selected interrupt is currently the highest 

includes an N-dimensional prioritized interrupt array 40 priority; and (3) a "Irq_processor" signal that interrupts the 

constructed as hardware register. In the illustrated example, 65 processor 30. When both the "Irq_selected" signal and the 

the interrupt array 40 has thirty-two entries (i.e., N«32). The "Highest_Irq" signal are asserted, an AND gate 66 outputs 

array 40 receives N interrupts 42, as represented by inter- the interrupt source number "Irq_Num". A multiplexer 68 
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uses the source number to locate the corresponding vector 
address for the ISR from the address field 50 of the priority/ 
address register 46. 

The interrupt handler 32 passes the interrupt source 
number and the vector address for the ISR to the processor. 
Upon receiving the interrupt signal "Irqjrocessor", the 
processor simply jumps to the address specified in the vector 
supplied by the interrupt handler 32. The output of scanning 
state machine 60 remains fixed until the interrupt service 
routine executed by the processor clears (resets) the interrupt 
source. At that time, the state machine will become active 
again, searching for a next highest priority interrupt to be 
serviced. 

Operation 

FIG. 3 is a state diagram showing a scanning process 
controlled by the scanning state machine 60. When no 
interrupts are active, the state machine 60 sits in an Idle State 
80. When one or more enabled interrupts go active and the 
OR gate 62 outputs an interrupt active signal (i.e., Irq_ 
active** 1), the state machine enters a Scanning State 82. 

For discussion purposes, suppose that the interrupt han- 
dler 32 receives three interrupts: "Int6", "Intll", and 
"Int30". Further, suppose that corresponding mask values 
"mask6", "maskll", and "mask30" in mask register 44 
indicate that all three interrupts are enabled. 

In the Scanning State 82, the state machine 60 scans the 
priority field 48 of the priority/address register 46 to deter- 
mine which of the active interrupts has the highest pro- 
grammed priority value. The state machine begins at the top 
of the array 40 and cycles through to the bottom to locate the 
interrupt source with the highest priority. The state machine 
initializes a "Current_Irq" count to zero, and sequentially 
steps through the array by incrementing by one the 
"Current_Irq". 

In this example, the state machine first encounters the 
priority level "Prill" for interrupt source "Int6". Thus far, 
this interrupt is initially considered to be the highest priority. 
The state machine 60 continues scanning until reaching the 
priority level "Pri3" of the next active interrupt "Intll". 
Priority level "Pri3" is higher than priority level "Prill" and 
hence the state machine substitutes, the priority level "Pri3" 
as the highest priority. 

Once again, the state machine 60 continues scanning until 
reaching the priority level "Pri3" of the third and final active 
interrupt "Int30". Notice that this interrupt source has the 
same priority level as the previous interrupt source. In this 
case, the scanning state machine 60 keeps the first- 
encountered interrupt source "Intll" as the highest priority 
interrupt. In this manner, the state machine 60 remembers 
the first-encountered interrupt source with the highest pri- 
ority level. 

After all sources have been scanned (i.e., Current_Jrq= 
31), the state machine transitions to an Interrupt Selected 
State 84, The state machine asserts the "Irq_Selected" 
signal and the "Highest_Irq" so that the AND gate 66 
outputs the interrupt source number "Irq_Num" of the 
highest priority interrupt to be serviced. The multiplexor 68 
locates the vector address in field 50 of the priority/address 
register 46 that corresponds to the highest priority interrupt 
and outputs that address. Here, the vector address "vector_ 
addrll" is an address of the interrupt service routine corre- 
sponding to interrupt "Intll". The state machine 60 asserts 
the processor interrupt "Irq__Processor" and provides the 
interrupt source number "Intll" and corresponding vector 
address "vector_addrll" as outputs for the processor to 
read. 
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The state machine 60 stays in the Interrupt Selected State 
84 until the interrupt "Intll" is inactive once again. The state 
machine then returns to the Idle State 80 and determines 
whether any enabled interrupts are active. In this example, 

5 interrupts "Int6" and "Int30" are still active and perhaps new 
interrupts have become active since the last scan. Therefore, 
the state machine 60 transitions immediately to the Scanning 
State 82 to locate the interrupt with the highest priority. 
Cascaded Architecture 

10 As noted above, multiple interrupt handlers may be 
arranged in a cascaded architecture where the output of one 
interrupt handler becomes an interrupt source to a next 
interrupt handler. For instance, in FIG. 1, the output of the 
interrupt handler 34 on support module 24 becomes interrupt 

15 source "Int9" of the interrupt handler 32 on CPU module 22. 
FIG. 4 shows the cascaded architecture in more detail and 
describes its operation. Suppose that the interrupt handler 34 
of support module 24, through its own internal scanning 
operation like that described above with respect to FIG. 3, 

20 determines that the interrupt source "IntA" is the highest 
priority interrupt currently pending. The remote interrupt 
handler 34 temporarily stores the interrupt source "IntA" 
and corresponding address "vector_addrA" for servicing 
the interrupt. The remote interrupt handler 34 then outputs 

25 an interrupt signal "Irq_IH34", which is received at the 
CPU-based interrupt handler 32 as interrupt source "Int9". 

Assuming that the interrupt "Int9" is enabled (i.e., as 
indicated by mask9 in interrupt handler 32), the scanning 

30 state machine 60 of interrupt handler 32 scans the priority 
field 48 to locate the highest priority active interrupt. Assum- 
ing that only interrupt "Int9" is active or that it is the highest 
priority among active interrupts, the state machine 60 scans 
the address field 50 to locate a corresponding address. 

35 In this case, the address field 50 holds an address for the 
state machine in the remote interrupt handler 34. Upon 
finding this address, the CPU-based interrupt handler 32 
starts a bus cycle on bus 26 to read the information currently 
being held at the remote interrupt handler 34 that corre- 

40 sponds to the interrupt source "IntA". The CPU-based 
interrupt handler 32 then outputs the interrupt source "IntA" 
and corresponding address "vector_addrA" to the processor 
30 for servicing. 

Programming Prioritized Interrupt Array 

45 The prioritized interrupt array 40 is programmable to set 
the interrupt priority levels in field 48 and the corresponding 
information in field 50 for servicing the interrupts. To 
program the priority field 48, an external chip select (CS) 
signal is applied to multiplexer 64 by the microprocessor 30 

50 to locate the particular priority slot and a five-bit value is 
written to the slot using standard I/O or memory-write 
instructions. Similarly, to program the address field 50, an 
external chip select (CS) signal is applied to multiplexer 68 
by the microprocessor 30 to locate the particular address slot 

55 and a 32-bit value is written to the slot. 

CONCLUSION 

Although the invention has been described in language 
specific to structural features and/or methodological steps, it 

60 is to be understood that the invention defined in the 
appended claims is not necessarily limited to the specific 
features or steps described. Rather, the specific features and 
steps are disclosed as preferred forms of implementing the 
claimed invention. 

65 What is claimed is: 

1. An interrupt handler for handling interrupts, compris- 
ing: 
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a programmable prioritized interrupt array that stores 
priority levels for associated interrupts and information 
for handling the associated interrupt; and 

a dynamic interrupt scanning state machine that scans the 
prioritized interrupt array upon receipt of one or more 
interrupts to locate the interrupt with a highest priority 
and identify the information for handling the interrupt 
with the highest priority. 

2. An interrupt handler as recited in claim 1, wherein the 
information comprises addresses to interrupt service rou- 
tines for servicing the associated interrupts. 

3. A computer comprising: 
a processor; and 

an interrupt handler as recited in claim 1 to handle 
interrupts for the processor. 

4. A vehicle computer for a vehicle comprising an inter- 
rupt handler as recited in claim 1. 

5. A vehicle computer for a vehicle, comprising: 

a CPU module with a processor and a first interrupt 
handler constructed as the interrupt handler recited in 
claim 1 to handle interrupts for the processor; 

a bus connected to the CPU module; and 

a support module connected to the bus, the support 
module having a second interrupt handler constructed 
as the interrupt handler recited in claim 1, the second 
interrupt handler supplying a highest priority interrupt 
derived at the support module as one of the interrupts 
handled by the first interrupt handler on the CPU 
module. 

An interrupt handler for handling interrupts, compris- 



6 

ing: 



ing: 



ing: 



9 

ing: 



10 



15 



20 



25 



30 



a programmable prioritized interrupt array that stores 
priority levels for associated interrupts and information 
for handling the associated interrupt; and 

an interrupt scanning state machine that scans the priori- 
tized interrupt array upon receipt of one or more 
interrupts to locate the interrupt with a highest priority 
and identify the information for handling the interrupt 
with the highest priority, wherein the information com- 
prises at least one address to a remote interrupt handler. 

7. An interrupt handler for handling interrupts, compris- 



35 



40 



a programmable prioritized interrupt array that stores 
priority levels for associated interrupts and information 
for handling the associated interrupt; and 

an interrupt scanning state machine that scans the priori- 
tized interrupt array upon receipt of one or more 
interrupts to locate the interrupt with a highest priority 
and identify the information for handling the interrupt 
with the highest priority, wherein the prioritized inter- 
rupt array may be programmed such that multiple 
different interrupts have identical priority levels. 

8. An interrupt handler for handling interrupts, compris- 



a programmable prioritized interrupt array that stores 
priority levels for associated interrupts and information 
for handling the associated interrupt; and 

an interrupt scanning state machine that scans the priori- 
tized interrupt array upon receipt of one or more 
interrupts to locate the interrupt with a highest priority 
and identify the information for handling the interrupt 
with the highest priority, wherein the interrupt scanning 
state machine scans the prioritized interrupt array 
sequentially. 

An interrupt handler for handling interrupts, compris- 



a programmable prioritized interrupt array that stores 
priority levels for associated interrupts and information 
for handling the associated interrupt; and 



60 



65 



an interrupt scanning state machine that scans the priori- 
tized interrupt array upon receipt of one or more 
interrupts to locate the interrupt with a highest priority 
and identify the information for handling the interrupt 
with the highest priority, wherein if the prioritized 
interrupt array locates an interrupt before scanning all 
of the prioritized interrupt array, the interrupt scanning 
state machine continues scanning until all of the pri- 
oritized interrupt array has been scanned to ensure that 
the interrupt with the highest priority is located. 

10. An interrupt handler for handling interrupts, compris- 
ing: 

a programmable prioritized interrupt array that stores 
priority levels for associated interrupts and information 
for handling the associated interrupt, wherein the pri- 
oritized interrupt array comprises: 
a mask register to hold mask values for corresponding 
ones of the interrupts to indicate whether the inter- 
rupts are enabled; and 
a priority/address register having a priority field to hold 
priority levels for the interrupts and an address field 
to hold addresses to interrupt service routines for 
servicing the associated interrupts; and 
an interrupt scanning state machine that scans the priori- 
tized interrupt array upon receipt of one or more 
interrupts to locate the interrupt with a highest priority 
and identify the information for handling the interrupt 
with the highest priority. 

11. An interrupt handler for handling interrupts, compris- 
ing: 

a programmable prioritized interrupt array that stores 
priority levels for associated interrupts and information 
for handling the associated interrupt; and 

an interrupt scanning state machine that scans the priori- 
tized interrupt array upon receipt of one or more 
interrupts to locate the interrupt with a highest priority 
and identify the information for handling the interrupt 
with the highest priority, wherein the interrupt scanning 
state machine is initially in an idle state until the 
prioritized interrupt array receives one or more inter- 
rupts; and whereupon receipt of the one or more 
interrupts, the interrupt scanning state machine transi- 
tions to a scanning state to scan the prioritized interrupt 
array and identify which of the one or more interrupts 
has a highest priority; and whereupon identifying the 
interrupt with the highest priority, the interrupt scan- 
ning state machine transitions to an interrupt selected 
state and accesses the prioritized interrupt array to 
output the information for handling the interrupt with 
the highest priority. 

12. An interrupt handler for handling interrupts, compris- 
ing: 

a programmable prioritized interrupt array for receiving 

one or more interrupts from multiple interrupt sources, 

the prioritized interrupt array having: 
a mask register to hold mask values for corresponding 

interrupt sources to indicate whether the interrupts from 

the interrupt sources are enabled; 
a priority register to hold priority levels for the interrupts 

received from the corresponding interrupt sources; 
an address register to hold information for handling the 

interrupts received from the corresponding interrupt 

sources; 

an interrupt scanning state machine coupled to the priori- 
tized interrupt array, the interrupt scanning state 
machine remaining in an idle state until the prioritized 
interrupt array receives one or more active interrupts 
that are indicated by the mark register as being enabled; 

whereeupon receipt of the one or more active interrupts, 
the interrupt scanning state machine transitions to a 
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scanning state to scan the priority register and identify 
which of the one or more active interrupts has a highest 
priority; and 

whereupon identifying the active interrupt with the high- 
est priority, the interrupt scanning state machine tran- 5 
sitions to an interrupt selected state and accesses the 
address register to output information for handling the 
active interrupt with the highest priority. 

13. An interrupt handler as recited in claim 12, wherein 
the address register holds addresses to interrupt service 3 q 
routines for servicing the interrupts received from the cor- 
responding interrupt sources. 

14. An interrupt handler as recited in claim 12, wherein 
the address register holds at least one address to a remote 
interrupt handler. 

15. An interrupt handler as recited in claim 12, wherein 15 
the priority register and the address register are program- 
mable. 

16. An interrupt handler as recited in claim 12, wherein 
the interrupt scanning state machine scans the priority 
register sequentially. 20 

17. A computer comprising: 
a processor; and 

an interrupt handler as recited in claim 12 to handle 
interrupts for the processor. 

18. A vehicle computer for a vehicle comprising an 25 
interrupt handler as recited in claim 12. 

19. A computing device comprising: 
a processor; 

an interrupt handler implemented in hardware and exter- 
nal to the processor to handle interrupts destined for the 30 
processor, the interrupt handler having programmable 
registers that define (1) whether interrupts from par- 
ticular interrupt sources are enabled, (2) priority levels 
of the interrupts, and (3) information for handling the 
interrupts; and 35 

upon receiving one or more interrupts, the interrupt han- 
dler through a dynamic state machine identifies a 
highest priority from among the one or more interrupts 
and provides an interrupt source identity and handling 
information for the highest priority interrupt to the 40 
processor. 

20. A computing device as recited in claim 19, stores 
addresses to interrupt service routines for servicing the 
interrupts. 

21. A computing device as recited in claim 19, embodied 
as a vehicle computer designed to reside in a vehicle. 

22. A computer system comprising: 
a bus; 

a computing device as recited in claim 19 coupled to the 
bus; and 

a remote interrupt handler coupled to the bus to supply an 
external interrupt to the intedrrupt handler of the com- 
puting device. 

23. A computing device comprising: 
a processor; 

an interrupt handler implemented in hardware and exter- 
nal to the processor to handle interrupts destined for the 
processor, the interrupt handler having programmable 
registers that define (1) whether interrupts from par- 
ticular interrupt sources are enabled, (2) priority levels 
of the interrupts, and (3) information for handling the 60 
interrupts; and 

upon receiving one or more interrupts, the interrupt han- 
dler identifies a highest priority from among the one or 
more interrupts and provides an interrupt source iden- 
tity and handling information for the highest priority 65 
interrupt to the processor, wherein multiple different 
interrupts are assigned with identical priority levels. 
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24. A computing device comprising: 
a processor; 

an interrupt handler implemented in hardware and exter- 
nal to the processor to handle interrupts destined for the 
processor, the interrupt handler having programmable 
registers that define (1) whether interrupts from par- 
ticular interrupt sources are enabled, (2) priority levels 
of the interrupts, and (3) information for handling the 
interrupts; and 

upon receiving one or more interrupts, the interrupt han- 
dler identifies a highest priority from among the one or 
more interrupts and provides an interrupt source iden- 
tity and handling information for the highest priority 
interrupt to the processor, wherein the interrupt handler 
comprises: 

a programmable prioritized interrupt array that interre- 
lates the programmable registers in a data structure; and 

an interrupt scanning state machine that scans the priori- 
tized interrupt array upon receipt of the one or more 
interrupts. 

25. A computing device as recited in claim 24, wherein the 
interrupt scanning state machine is initially in an idle state 
until the prioritized interrupt array receives the one or more 
interrupts; and whereupon receipt of the one or more 
interrupts, the interrupt scanning state machine transitions to 
a scanning state to scan the prioritized interrupt array and 
identify which of the one or more interrupts has a highest 
priority; and whereupon identifying the interrupt with the 
highest priority, the interrupt scanning state machine tran- 
sitions to an interrupt selected state and accesses the priori- 
tized interrupt array to output the information for handling 
the interrupt with the highest priority. 

26. A computing device comprising: 
a processor; 

an interrupt handler implemented in hardware and exter- 
nal to the processor to handle interrupts destined for the 
processor, the interrupt handler having programmable 
registers that define (1) whether interrupts from par- 
ticular interrupt sources are enabled, (2) priority levels 
of the interrupts, and (3) information for handling the 
interrupts; and 

upon receiving one or more interrupts, the interrupt han- 
dler identifies a highest priority from among the one or 
more interrupts and provides an interrupt source iden- 
tity and handling information for the highest priority 
interrupt to the processor, wherein one of the interrupt 
sources is a remote interrupt handler. 

27. A method for handling interrupts comprising: 
awaiting receipt of one or more interrupts; 

upon receipt of the one or more interrupts, scanning using 
a dynamic state machine a prioritized interrupt array to 
determine which interrupt has a highest priority; and 

upon identifying the interrupt with the highest priority, 
accessing the prioritized interrupt array to obtain infor- 
mation for handling the interrupt with the highest 
priority. 

28. A method for handling interrupts comprising: 
awaiting receipt of one or more interrupts; 

upon receipt of the one or more interrupts, scanning a 
prioritized interrupt array to determine which interrupt 
has a highest priority; 

upon identifying the interrupt with the highest priority, 
accessing the prioritized interrupt array to obtain infort- 
nation for handling the interrupt with the highest pri- 
ority; and 

repeating the scanning and the accessing until all of the 
one or more interrupts have been handled. 
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ABSTRACT 



An interrupt handler is provided for a real-time control 
system that prevents interrupts which occur asynchronously 
with respect to control tasks from upsetting guarantees of 
timely execution of the control tasks. For interrupts associ- 
ated with the communication of messages between portions 
of a control task over the distributed system, the interrupts 
are converted to proxy tasks that may be scheduled like any 
task in a multitasked-operated system. More generally, inter- 
rupts may be assigned to a predetermined interrupt window 
being a portion of the total processing bandwidth of the 
processor. In pre-allocating the processor bandwidth to the 
control tasks, this interrupt window may be subtracted out 
thereby guaranteeing adequate bandwidth for both interrupt 
processing and user tasks. 

11 Claims, 6 Drawing Sheets 
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DISTRIBUTED REAL-TIME OPERATING 
SYSTEM PROVIDING INTEGRATED 
INTERRUPT MANAGEMENT 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application claims the benefit of provisional appli- 
cation Sen No. 60/148,541 filed Aug. 12, 1999. 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 

BACKGROUND OF THE INVENTION 

The present invention relates to industrial controllers for 
controlling industrial processes and equipment, and more 
generally to an operating system suitable for a distributed 
industrial control system having multiple processing nodes 
spatially separated about a factory or the like. 

Industrial controllers are special purpose computers used 
for controlling industrial processes and manufacturing 
equipment. Under the direction of a stored control program 
the industrial controller examines a series of inputs reflect- 
ing the status of the controlled process and in response, 
adjusts a series of outputs controlling the industrial process. 
The inputs and outputs may be binary, that is on or off, or 
analog providing a value within a continuous range of 
values. 

Centralized industrial controllers may receive electrical 
inputs from the controlled process through remote input/ 
output (I/O) modules communicating with the industrial 
controller over a high-speed communication network. Out- 
puts generated by the industrial controller are likewise 
transmitted over the network to the I/O circuits to be 
communicated to the controlled equipment. The network 
provides a simplified means of communicating signals over 
a factory environment without multiple wires and the atten- 
dant cost of installation. 

Effective real-time control is provided by executing the 
control program repeatedly in high speed "scan" cycles. 
During each scan cycle each input is read and new outputs 
are computed. Together with the high-speed communica- 
tions network, this ensures the response of the control 
program to changes in the inputs and its generation of 
outputs will be rapid. All information is dealt with centrally 
by a well-characterized processor and communicated over a 
known communication network to yield predictable delay 
times critical to deterministic control. 

The centralized industrial controller architecture, 
however, is not readily scalable, and with foreseeably large 
and complex control problems, unacceptable delays will 
result from the large amount of data that must be commu- 
nicated to a central location and from the demands placed on 
the centralized processor. For this reason, it may be desirable 
to adopt a distributed control architecture in which multiple 
processors perform portions of the control program at spa- 
tially separate locations about the factory. By distributing the 
control, multiple processors may be brought to bear on the 
control problem reducing the burden on any individual 
processor and the amount of input and output data that must 
be transmitted. 

Unfortunately, the distributed control model is not as well 
characterized as far as guaranteeing performance as is 
required for real-time control. Delay in the execution of a 
portion of the control program by one processor can be fatal 
to successful real-time execution of the control program, and 
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because the demand for individual processor resources 
fluctuates, the potential for an unexpected overloading of a 
single processor is possible. This is particularly true when a 
number of different and independent application programs 

5 are executed on the distributed controller and where the 
application programs compete for the same set of physical 
hardware resources. 

One problem in ensuring timely execution of tasks in a 
distributed environment arises in the processing of inter- 

30 rupts. Interrupts are electrical signals acting directly on the 
hardware of the processor to cause the processor to stop its 
current execution of a program and respond, typically, to an 
external device requiring immediate attention. Interrupts 
avoid inefficient polling by the processor of asynchronous 

15 signals and thus greatly improve the efficiency of some types 
of processing. Implicitly, interrupts normally have the high- 
est priority with respect to response by the processor. A 
distributed control system with its attendant increased need 
for intercommunication among disparate components, may 

20 make extensive use of interrupts. 

Unfortunately, because interrupts occur asynchronously 
to the execution of task on the processor, there exists the 
possibility that a large number of interrupts will occur within 
a small window of time thus preventing the timely execution 

25 of the task which is being interrupted. When the interrupts 
are caused by low priority tasks, the effects of this is a 
priority inversion where lower priority tasks displace higher 
priority tasks. This may lead to the failure of time critical 
tasks. 

30 

SUMMARY OF THE INVENTION 

The present invention provides two methods of managing 
interrupts in the context of a real-time control system where 

35 task execution must proceed according to guaranteed 
completion times. For those interrupts associated with 
incoming messages and remote services provided by the 
operating system, the interrupts are embedded into a proxy 
task which is scheduled along with other tasks executed by 

4Q a multitasking operating system. The proxy task may pre- 
empt the current task or may wait its turn depending on its 
priority. 

All interrupts, are allocated to an interrupt window being 
a fixed percentage of time of the processor bandwidth. If 

45 interrupt window time is available, the interrupt is pro- 
cessed. Nested interrupting is allowed providing for a high 
degree of responsiveness of the control system. The interrupt 
window is subtracted from the of bandwidth of the processor 
that may be allocated in pre-allocation of bandwidth to 

50 application programs. Accordingly, guarantees of timely 
execution of programs having pre-allocated bandwidth may 
be ensured despite asynchronous interrupts such as may 
occur during run time. 

Specifically, the present invention provides an interrupt 

55 manager for use with a processor forming part of a distrib- 
uted control system. The interrupt manager includes inter- 
rupt reception circuitry receiving interrupt signals including 
a current interrupt. An interrupt window counter stores a 
value indicating the time remaining in a current window for 

60 the service of interrupts. The interrupt window counter is 
reset by a window timer at the expiration of each window 
period. A masking circuit masks current interrupts when the 
current interrupt would cause the value of the interrupt 
window counter to exceed the pre-allocated interrupt period. 

65 Thus, it is one object of the invention to limit the servicing 
of interrupts to a finite period within each processing win- 
dow. In this way, an arbitrary confluence of interrupts will 
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not upset the deterministic execution of control tasks that 
must adhere to deadlines. The interrupt manager may mask 
interrupts until the determination is made as to whether the 
current interrupt may be executed. 

Thus, it is another object of the invention to allow the 5 
initial evaluation of an interrupt to proceed without further 
interruptions. 

The interrupt manager may determine whether the current 
interrupt may be processed by adding an estimate of the time 
for processing the current value of the interrupt window 30 
counter. The estimation may be modified during actual 
execution of the interrupt. 

Upon the determination that the current interrupt may be 
executed within the interrupt window, the interrupts are 
unmasked. 15 

It is yet another object of the invention to permit nested 
interrupts such as provides for responsive operation of the 
interrupt process. 

Thus, it is another object of the invention to provide for 2 o 
simple before-the-fact determination of whether an interrupt 
can proceed by allowing the use of a conservative estimate 
that is refined during run time. 

It is yet another object of the invention to allow for the 
processing of subsequent nested interrupts by pre -estimating 25 
the amount of time required by each interrupt as it is 
received. In this way, nested interrupts may be accepted 
prior to an initial interrupt being completed. 

Upon completion of the interrupt, the interrupt manager 
may add the estimate of the interrupt processing time and 30 
subtract the actual interrupt processing time from the value 
of the interrupt window counter. 

Thus, it is another object of the invention to provide 
accurate accounting of actual interrupt time used while 
allowing pre-allocation of the interrupt time window. 35 

The interrupt manager may cease masking the current 
interrupt upon resetting of the interrupt window counter by 
the timer. 

It is, therefore, another object of the invention to allow 
stalled interrupts to nevertheless execute in order. 

The interrupt manager may include a resource allocating 
operating system prc-allocating portions of the window 
period, excluding the predetermined interrupt window, to 
multiple tasks to be executed on the processor so as to 45 
guarantee timely execution of those tasks. 

Thus, it is another object of the invention to allow 
pre-allocation of hardware resources to particular control 
tasks while guaranteeing interrupts will not usurp that allo- 
cation. 50 

For the communication circuit in which the interrupts are 
related to incoming messages, the interrupt manager may 
include a task scheduler receiving tasks and arranging them 
in a queue according to priorities for execution by the 
processor. The communication circuit may receive messages 55 
having priorities to generate a communication interrupt. An 
interrupt reception circuit may receive the communication 
interrupts and the priorities and generate corresponding 
proxy tasks having the priority and enroll the proxy task on 
the task scheduler queue. 60 

Thus, it is another object of the invention to provide a 
mechanism for processing interrupts for communication 
devices when messages form connections between tasks 
executed on spatially separate hardware making use of the 
same scheduling framework as the rest of the tasks thereby 65 
guaranteeing timely execution of the task as is necessary for 
real-time control. 
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The task scheduler may consider both the priority and 
time constraint value. 

Thus, it is another object of the invention to provide for 
a mixed priority scheduling of interrupts through the use of 
a proxy task. 

The foregoing and other objects and advantages of the 
invention will appear from the following description. In the 
description, reference is made to the accompanying draw- 
ings which form a part hereof and in which there is shown 
by way of illustration a preferred embodiment of the inven- 
tion. Such embodiment does not necessarily represent the 
full scope of the invention, however, and reference must be 
made to the claims herein for interpreting the scope of the 
invention. 

BRIEF DESCRIPTION OF TOE SEVERAL 
VIEWS OF THE DRAWINGS 

FIG. 1 is a simplified diagram of a distributed control 
system employing two end nodes and an intervening com- 
munication node and showing the processor, memory and 
communication resources for each node; 

FIG. 2 is a block diagram showing the memory resources 
of each node of FIG. 1 as allocated to a distributed real-time 
operating system and different application programs; 

FIG. 3 is an expanded block diagram of the distributed 
operating system of FIG. 2 such as includes an application 
list listing application programs to be executed by the 
distributed control system, a topology showing the topology 
of the connection of the hardware resources of the nodes of 
FIG. 1, a resource list detailing the allocation of the hard- 
ware resources to the application program and the statistics 
of their use by each of the application programs, and the 
executable distributed real-time operating system code; 

FIG. 4 is a pictorial representation of a simplified appli- 
cation program attached to its high-level requirements; 

FIG. 5 is a flow chart of the operation of the distributed 
real-time operating system code of FIG. 3 showing steps 
upon accepting a new application program to determine the 
low-level hardware resource requirements and to seek com- 
mitments from those hardware resources for the require- 
ments of the new application program; 

FIG. 6 is a detailed version of the flow chart of FIG. 5 
showing the process of allocating low-level requirements to 
hardware resources; 

FIG. 7 is a block diagram detailing the step of the flow 
chart of FIG. 5 of responding to requests for commitment of 
hardware resources; 

FIG. 8a is a detailed view of the communication circuit of 
FIG. 1 showing a messaging queue together with a scheduler 
and a history table as may be implemented via an operating 
system and showing a message received by the communi- 
cation circuit over the bus of FIG. 1; 

FIGS. 8b is a figure similar to that of FIG. 8a showing the 
scheduler of FIG. 8a as implemented for multi-tasking of the 
processors of FIG. 1; 

FIG. 9 is a flow chart showing the steps of operation of 
enrolling the message of FIG. 8a or tasks of FIG. 8b into a 
queue; 

FIG. 10 is a schematic representation of the interrupt 
handling system provided by the operating system and 
processor of FIGS, 1 and 2; and 

FIG. 11 is a flow chart showing the steps of operation of 
the interrupt handling system of FIG. 10. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Distributed Control System 
Referring now to FIG. 1, a distributed control system 10 
includes multiple nodes 12a, 12b and 12c for executing a 



01/20/2004, EAST version: 1.4.1 



US 6,633,942 Bl 

5 6 

control program comprised of multiple applications. Control operation of the distributed control system 10. First, an 

end nodes 12a and 12c include signal lines 14 communi- application list 36 lists the application programs 34 that have 
eating between the end nodes 12a and 12c and a portion of been accepted for execution by the distributed control sys- 

a controlled process 16a and 16b, Controlled process por- tem 10. Contained in the application list 36 are application 

tions 16a and 166 may communicate by a physical process 5 identifiers 38 and high-level requirements 40 of the appli- 

flow or other paths of communication indicated generally as cation programs as will be described below, 

dotted line 18. A hardware resource list 44 provides (as depicted in a first 

In the present example, end node 12a may receive signals column) a comprehensive listing of each hardware resource 

A and B from process 16a, and end node 12c may receive of the distributed control system 10 indicating a quantitative 

signal C from process 16b and provide as an output signal 1Q measure of that resource. For example, for the principle 

D to process 166 as part of a generalized control strategy. hardware resources of processors 26, networks 31 and 

End nodes 12a and 12c include interface circuitry 20a and memories 24, quantitative measurements may be provided 
20c, respectively, communicating signals on signal lines 14 in terms of millions of instructions per second (MIPs) for 
to internal buses 22a and 22c, respectively. The internal processors 26, numbers of megabytes for memories 24 and 
buses 22a and 22c may communicate with the hardware megabaud bandwidth for networks. While these are the 
resources of memory 24a, processor 26a and communica- 15 principal hardware resources and their measures, it will be 
tion card 28a (for end node 12a) and memory 24c, processor understood that other hardware resources may also be 
26c, and network communication card 28c for end node 12c. enrolled in this first column and other units of measures may 
Communication card 28a may communicate via network be used. Generally, the measures are of "bandwidth", a term 
media 30a to a communication card 286 on node 12b which encompassing both an indication of the amount of data and 
may communicate via internal bus 226 to memory 246 and 2 ° the frequency of occurrence of the data that must be pro- 
processor 266 and to second network communication card cessed. 

28i .connected to media 30ft which in turn communicates A aecoai column of the hardware resource list 44 

wnh communication card 28c. vides aQ allocation of the quantitative measure of the 

Generally during operation of distributed control system resourC6 of a particular row t0 one or more a p plication 

application programs are allocated between memories 24a 25 ams from the application list 36 identified by an 

246 and 24c to be executed on the respective nodes 12a, 126 ?• .■ _ t*. .■ * iT .i_ 

. n ... 4 . r i- 1 ia application name. Ine application name may match the 

and 12c with communications as necessary over links 30a • , ,. r ~„ r A\. , . , , 

and 306. In an example control task, it may be desired to ^PP^ation identifier 38 of the application list 36 and the 

produce signal D upon the logical conjunction of signals A, indicated allocation quantitative measure will typically be a 

B and C. In such a control task, a program in memory 24a 30 P ortlon of the quantitative measure of the first column, 

would monitor signals A and B and send a message indi- A tnird column of the hardware resource list 44 provides 

eating both were true, or in this example send a message an actual usage of the hardware resource by the application 

indicating the state of signals A and B to node 12c via a path program as may be obtained by collecting statistics during 

through communication 28a, 286, 286' and 28c. running of the application programs. This measure will be 

A portion of the application program executed by proces- 35 statistical in nature and may be given in the units of the 

sor 26c residing in memory 24c would detect the state of quantitative measure for the hardware resource provided in 

input C and compare it with the state of signals A and B in the first column. 

the received message to produce output signal D. The operating system 32 also includes a topology map 42 

The proper execution of this simple distributed applica- indicating the connection of the nodes 12a, 126 and 12c 

tion program requires not only the allocation of the appli- through the network 31 and the location of the hardware 

cation program portions to the necessary nodes 12a, 126 and resources of the hardware resource list 44 in that topology. 

12c but prompt and reliable execution of those programs, Finall the ati tem alsQ indudes an Q f 

the latter which requires the hardware resource. .of memory tem ^ 48 such ^ read ^ lication lis ^ 6> ^ 

processor, and communication networks 28a, 30a, 286. 286 / , A ~ , , , r i-*^. 

306 and 28c topology map 42, and the hardware resource list 44 to ensure 

r> c * 4 i-i^ i r i » .as proper operation of the distributed control system 10. 

Referring now to FIG. 2 for this latter purpose, the 3 „ r • ™^ a . . 
distributed real-time operating system 32 of the present Referring now to FIG. 4, each application program 
invention may be used such as may be centrally located in enrolled in the application list 36 is associated with high- 
one node 12 or in keeping with the distributed nature of the level requirements 40 which will be used by the operating 
control system distributed among the nodes 12a, 126 and s y stem code ^ Generally, these high-level requirements 40 
12c. In the latter case, the portions of the operating system 50 will be determined by the programmer based on the pro- 
32 are stored in each of the memories 24a, 246 and 24c and gammer's knowledge of the controlled process 16 and its 
intercommunicate to operate as a single system. In the requirements. 

preferred embodiment, a portion of the operating system 32 Thus* f° r tne application described above with respect to 

that provides a modeling of the hardware resources (as will FIG - h tne application program 34 may include a single 

be described) is located in the particular node 12a, 126 and 55 ladder rung 50 (shown in FIG. 4) providing for the logical 

12c associated with those hardware resources. Thus, hard- ANDing of inputs A, B and C to produce an output D. The 

ware resource of memory 24a in node 12a would be high-level requirements 40 would include hardware require- 

modeled by a portion of the operating system 32 held in meats for * n P uts and outputs A, B, C and D. The high-level 

memory 24a. requirements 40 may further include "completion-timing 

In addition to portions of the operating system 32, 60 constraints" t a and indicating a constraint in execution time 

memory 24a, 246 and 24c include various application pro- of the application program 34 needed for real-time control, 

grams 34 or portions of those application programs 34 as Generally the completion-timing constraint is a maximum 

may be allocated to their respective nodes. P eriod of time that may elapse between occurrences of the 

last of inputs A, B and C to become logically true and the 

Integrated Resource Management 65 occurrence of the output signal D. 

Referring now to FIG. 3, the operating system 32 collec- The high-level requirements 40 may also include a mes- 

tively provides a number of resources for ensuring proper sage size, in this case the size of a message AB which must 
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be sent over the network 31, or this may be deduced 
automatically through use of the topology map 42 and an 
implicit allocation of the hardware. 

Finally, the high-level requirements 40 include an "inter- 
arrival period" t 2 reflecting an assumption about the statis- 5 
tics of the controlled process 16a in demanding execution of 
the application program 34. As a practical matter the inter- 
arrival period t 2 need be no greater than the scanning period 
of the input circuitry 20a and 20c which may be less than the 
possible bandwidth of the signals A, B and C but which will 10 
provide acceptable real-time response. 

Referring now to FIG. 5, the operating system code 48 
ensures proper operation of the distributed control system 10 
by checking that each new enrolled application program 34 
will operate acceptably with the available hardware 15 
resources. Prior to any new application program 34 being 
added to the application list 36, the operating system code 48 
intervenes so as to ensure the necessary hardware resources 
are available and to ensure that time guarantees may be 
provided for execution of the application program. 

At process block 56, the operating system code 48 checks 
that the high-level requirements 40 have been identified for 
the application program. This identification may read a 
prepared file of the high-level requirements 40 or may solicit 25 
the programmer to input the necessary information about the 
high-level requirements 40 through a menu structure or the 
like, or may be semiautomatic involving a review of the 
application program 34 for its use of hardware resources and 
the like. As shown and described above with respect to FIG. 3Q 
4, principally four high-level requirements are anticipated 
that of hardware requirements, completion-timing 
constraints, message sizes, and the inter-arrival period. 
Other high-level requirements are possible including the 
need for remote system services, the type of priority of the 
application, etc. 

Referring still to FIG. 5, as indicated by process block 58, 
the high-level requirements 40 are used to determine low- 
level requirements 60. These low-level requirements may be 
generally "bandwidths" of particular hardware components 40 
such as are listed in the first column of the hardware resource 
list 44. Generally, the low-level requirements will be a 
simple function of high-level requirements 40 and the objec- 
tive characteristics of the application program 34, the func- 
tion depending on a priori knowledge about the hardware 4S 
resource. For example, the amount of memory will be a 
function of the application program size whereas, the net- 
work bandwidth will be a function of the message size and 
the inter-arrival period t 2 , and the processor bandwidth will 
be a function of the application program size and the 50 
inter-arrival period t 2 as will be evident to those of ordinary 
skill in the art. As will be seen, it is not necessary that the 
computation of the low-level requirements 60 be precise so 
long as it is a conservative estimate of low-level resources 
required. 55 

The distinction between high-level requirements 40 and 
low-level requirements 60 is not fixed and in fact some 
high-level requirements, for example message size, may in 
fact be treated as low-level requirements as deduced from 
the topology map 42 as has been described. 60 

Once the low-level requirements 60 have been determined 
at process block 62, they are allocated to particular hardware 
elements distributed in the control system 10. Referring also 
to FIG. 6, the process block 62 includes sub-process block 
63 where the low-level requirements abstracted at process 65 
block 58 are received. At process block 66, end nodes 12a 
and 12c are identified based on their hardware links to inputs 
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A, B and C and output D and a tentative allocation of the 
application program 34 to those nodes and an allocation of 
necessary processor bandwidth is made to these principal 
nodes 12a and 12c. Next at process block 68 with reference 
to the topology map 42, the intermediary node 12b is 
identified together with the necessary network 31 and an 
allocation is made of network space based on message size 
and the inter-arrival period. 

The burden of storing and executing the application 
program is then divided at process block 70 allocating to 
each of memories 24a and 24c (and possibly 126), a certain 
amount of space for the application program 34 and to 
processors 26a and 26c (and possibly 26b) a certain amount 
of their bandwidth for the execution of the portions of the 
application program 34 based on the size of the application 
program 34 and the inter-arrival period t 2 . Network cards 
28a, 2Sb\ 28b and 28c also have allocations to them based 
on the message size and the inter-arrival period t^ Thus, 
generally the allocation of the application program 34 can 
include intermediate nodes 12b serving as bridges and 
routers where no computation will take place. For this 
reason, instances or portions of the operating system code 48 
will also be associated with each of these implicit hardware 
resources. 

There are a large number of different allocative 
mechanisms, however, in the preferred embodiment the 
application program is divided according to the nodes asso- 
ciated with its inputs per U.S. Pat. No. 5,896,289 to Struger 
issued Apr. 20, 1999 and entitled: "Output Weighted Parti- 
tioning Method for a Control Program in a Highly Distrib- 
uted Control System" assigned to the same assignee as the 
present invention and hereby incorporated by reference.. 

During this allocation of the application program 34, the 
completion-timing constraint t a for the application program 
34 is divided among the primary hardware to which the 
application program 34 is allocated and the implicit hard- 
ware used to provide for communication between the pos- 
sibly separated portions of the application program 34. Thus, 
if the completion-timing constraint t x is nine milliseconds, a 
guaranty of time to produce an output after necessary input 
signals are received, then each node 12a^c will receive three 
microseconds of that allocation as a time obligation. 

At process block 72, a request for a commitment based on 
this allocation including the allocated time obligations and 
other low-level requirements 60 is made to portions of the 
operating system code 48 associated with each hardware 
element. 

At decision block 64, portions of the operating system 
code 48 associated with each node 12a-c and their hardware 
resources review the resources requested of them in 
processor, network, and memory bandwidth and the allo- 
cated time obligations and reports back as to whether those 
commitments may be made keeping within the allocated 
time obligation. If not, an error is reported at process block 
66. Generally, it is contemplated that code portions respon- 
sible for this determination will reside with the hardware 
resources which they allocate and thus may be provided with 
the necessary models of the hardware resources by the 
manufacturers. 

This commitment process is generally represented by 
decision block 64 and is shown in more detail in FIG. 7 
having a first process block 74 where a commitment request 
is received designating particular hardware resources and 
required bandwidths. At process block 76, the portion of the 
operating system code 48 associated with the hardware 
element allocates the necessary hardware portion from hard- 
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ware resource list 44 possibly modeling it as shown in tive data of the message and the routing information of the 

process block 78 with the other allocated resources of the message necessary for transmission on the network 31. In 

resource list representing previously enrolled application addition, the message 91 will also include scheduling data 

programs 34 to see if the allocation can be made. In the case 100 which may be physically attached to the message data 

of the static resources such as memory, the allocation may 5 99 or associated with the message data 99 by the operating 

simply be a checking of the hardware resource list 44 to see system 32. 

if sufficient memory is available. In dynamic resources such The scheduling data 100 includes a user- assigned priority 

as the processors and the network, the modeling may deter- 96 generally indicating a high priority for messages associ- 

mine whether scheduling may be performed such as will ated with time critical tasks. The priority 96 is taken from the 

allow the necessary completion-timing constraints tj given 10 priority of the application program 34 of which the message 

the inter-arrival period ^ of the particular application and 91 form a part and is determined prior to application 

other applications. program based on the importance of its control task as 

At the conclusion of the modeling and resource allocation determined by the user, 

including adjustments that may be necessary from the mod- The scheduling data 100 may also include a execution 

eling at process block 80, a report is made back to the other 15 period (EP) indicating the length of time anticipated to be 

components of the operating system code 48. If that report necessary to execute the message for transmission on the 

is that a commitment may be had for all hardware resources network 31 and a deadline period (DP) being in this case the 

of the high-level requirements 40, then the program pro- portion of the completion timing constraint l ± allocated to 

ceeds to process block 82 instead of process block 66 the particular communication card 28 for transmission of the 

representing the error condition as has been described. 20 message 91. The scheduling data 100 also includes a task 

At process block 82, a master hardware resource list 44 is identification (TID) identifying the particular message 91 to 

updated and the application program is enrolled in the an application program 34 so that the high level require- 

application list 36 to run. ments of the application program 34, imputed to the message 

During execution of the application program 34 and as „ 91 as wil1 be described, may be determined from the 

indicated by process block 84, statistics are collected on its application list 30 described above, and so that the resources 

actual bandwidth usage for the particular hardware resources and bandwidths allocated to the application program and its 

to which it is assigned. These are stored in the third column P orlion held in resource list 44 can be accessed by the 

of the hardware resource list 44 shown in FIG. 3 and is communication card 28 and the scheduler 94. 

shown in the block 45 associated with FIG. 5 and may be 3Q The scheduling data 100 may be attached by the operating 

used to change the amount of allocation to particular appli- system 32 and in the simplest case is derived from data 

cation programs 34, indicated by arrow 86, so as to improve entered by the control system programmer. The execution 

hardware resource utilization. period after entry, may be tracked by the operating system 

during run-time and modified based on that tracking to 

Scheduled Communication Queuing ^ provide for accurate estimations of the execution period over 

Referring now to FIG. 8a, the communication card 28 will time * 

typically include a message queue 90 into which messages Upon arrival of a message at the communication card 28, 

91 are placed prior to being transmitted via a receiver/ the scheduling data 100 and the message data 99 are 

transmitter 92 onto the network 31. A typical network provided to the scheduler 94. The scheduler 94 notes the 

queuing strategy of First-In-First-Out (FIFO) will introduce 40 arrival time based on a system clock (not shown) and 

a variable delay in the transmission of messages caused by calculates a LATEST STARTING TIME for the message 

the amount of message traffic at any given time. Of partial- (LST) as equal to a deadline time minus the execution 

lar importance, messages which require completion on a period. The deadline time is calculated as the message 

timely basis and which therefore have a high priority may arrival time plus the deadline period provided in the mes- 

nevertheless be queued behind lower level messages without 45 sage. 

time criticality. In such a queue 90, priority and time Referring now to FIG. 9, arrival of the message at the 

constraints are disregarded, therefore even if ample network communication card 28 is indicated generally at process 

bandwidth is available and suitable priority attached to block 101 and is represented generally as a task, reflecting 

messages 91 associated with control tasks, the completion the fact that the same scheduling system may be used for 

timing constraints t A cannot be guaranteed. 50 other than messages as will be described below. 

To overcome this limitation, the communication card 28 Following process block 101 is decision block 102 which 

of the present invention includes a queue-level scheduler 94 determines whether the bandwidth limits for the task have 

which may receive messages 91 and place them in the queue been violated. The determination of bandwidth limits at 

90 in a desired order of execution that is independent of the block 102 considers, for example, the inter-arrival period t^ 

arrival time of the message 91. The scheduler 94 receives the 55 for the messages 91. A message 91 will not be scheduled for 

messages 91 and places them in the queue 90 and includes transmission until the specified inter-arrival period ^ expires 

memory 98 holding a history of execution of messages for the previous transmission of the message 91. The expi- 

identified to their tasks as will be described below. Generally ration time of the inter-arrival period ^ is stored in the 

the blocks of the queue 90, the scheduler 94 and the memory history memory 98 identified to the TID of the message. This 

98 are realized as a portion of the operating system 32, 60 ensures that all guarantees for message execution can be 

however, they may alternatively be realized as an applica- honored. More generally for a task other than a message, the 

tion specific integrated circuit (ASIC) as will be understood bandwidth limits may include processor time or memory 

in the art. allocations. 

Each message 91 associated with an application program If at process block 102, there is no remaining allocation 

for which a time constraint exists (guaranteed tasks) to be 65 of network bandwidth for the particular task and the task is 

transmitted by the communication card 28 will contain guaranteed, it is not executed until the bandwidth again 

conventional message data 99 such as may include substan- becomes available. 
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At succeeding block 104, if the bandwidth limits have not 
been violated, the message is placed in the queue 90 
according to its user priority 96. Thus, high priority mes- 
sages always precedes low priority messages in the queue 
90. The locking out of low priority messages is prevented by 
the fact that the high priority messages must have guaran- 
teed bandwidths and a portion of the total bandwidth for 
each resource, the communication card 28, for example, is 
reserved for low priority tasks. 

At decision block 106, it is determined whether there is a 
priority tie, meaning that there is another message 91 in the 
queue 90 with the same priority as the current message 91. 
If not, the current message 91 is enrolled in the queue 90 and 
its position need not be recalculated although its relative 
location in the queue 90 may change as additional messages 
are enrolled. 

If at decision block 106 there is a priority tie, the 
scheduler 94 proceeds to process block 108 and the mes- 
sages with identical priorities are examined to determine 
which has the earliest LATEST STARTING TIME. The 
LATEST STARTING TIME as described above is an abso- 
lute time value indicating when the task must be started. As 
described above the LATEST STARTING TIME need only 
be computed once and therefore doesn't cause unbounded 
numbers of context switches. The current message is placed 
in order among the message of a similar priority according 
to the LATEST STARTING TIME with earliest LATEST 
STARTING TIME first. 

If at succeeding process block 110, there is no tie between 
the LATEST STARTING TIMES, then the enrollment pro- 
cess is complete. Otherwise, the scheduler 94 proceeds to 
process block 112 and the messages are examined to deter- 
mine their deadline periods DP as contained in the sched- 
uling data 100. A task with a shorter deadline period is 
accorded the higher priority in the queue 90 on the rationale 
that shorter deadline periods indicate relative urgency. 

At succeeding process block 114 if there remains a tie 
according to the above criteria between messages 91, then at 
process block 116, the tie is broken according to the execu- 
tion period, EP, of the messages 91. Here the rationale is that 
in the case of transient overload, executing the task with the 
shortest execution period will ensure execution of the great- 
est number of tasks. 

A system clock with sufficient resolution will prevent a tie 
beyond this point by ensuring that the LATEST STARTING 
TIMES are highly distinct. 

These steps of determining priority may be simplified by 
concatenating the relevant scheduling data 100 into a single 
binary value of sufficient length. The user priority forms the 
most significant bits of this value and execution period the 
least significant bits. This binary value may then be exam- 
ined to place the messages (or tasks) in the queue 90. 

As each message 91 rises to the top of the queue 90 for 
transmission, its LATEST STARTING TIME is examined to 
see if it has been satisfied. Failure of the task to execute in 
a timely fashion may be readily determined and reported. 

Mixed Priority Multi-Tasking 

As mentioned, the scheduling system used for the com- 
munication card 28 described above is equally applicable to 
scheduling other resources within the distributed operating 
system, for example, the processors 26. Referring to FIG. 
86, each processor 26 may be associated with a task queue 
119 being substantially identical to the message queue 90 
except that each slot in the task queue 119 may represent a 
particular bandwidth or time slice of processor usage. In this 
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way, enrolling a task in the task list not only determines the 
order of execution but allocates a particular amount of 
processor resources to that task. New tasks are received 
again by a scheduler 94 retaining a history of the execution 

5 of the task according to task identification (HD) in memory 
98 and enrolling the tasks in one of the time slots of the task 
queue 119 to be forwarded to the processor 26 at the 
appropriate moment. The tasks include similar tasks sched- 
uling data as shown in FIG. 8a but need not include a 

10 message data 99 and may rely on the TID to identify the task 
implicitly without the need for copying the task into a 
message for actual transmission. 

Referring to FIG. 9, the operation of the scheduler 94 as 
with the case of messages above, only allocates to the task 

15 the number of time slots in the queue 90 as was reserved in 
its bandwidth allocation in the resource list 44. In this way, 
it can be assured that time guarantees may be enforced by 
the operating system. 

20 Interrupt Management 

As is understood in the art, interrupts normally act directly 
on the processor 26 to cause the processor 26 to interrupt 
execution of a current task and to jump to an interrupt 
subroutine and execute that subroutine to completion before 
returning to the task that was interrupted. The interrupt 
process involves changing the value of the program counter 
to the interrupt vector and saving the necessary stack and 
registers to allow resumption of the interrupt routine upon 
3Q completion. Typically interrupt signals may be masked by 
software instructions such as may be utilized by the oper- 
ating system in realizing the mechanism to be described 
now. 

Referring now to FIGS. 8a and 86, a similar problem to 

35 that described above, of lower priority messages blocking 
the execution of higher priority messages in the message 
queue 90, may occur with interrupts. For example, a system 
may be executing a time critical user task when a low 
priority interrupt, such as that which may occur upon receipt 

40 of low priority messages, may occur. Since interrupts are 
serviced implicitly at a high priority level, the interrupt 
effects a priority inversion with the high priority task waiting 
for the low priority task. If many interrupts occur, the high 
priority tasks may miss its time guarantee. 

45 This problem may be solved in two ways. Referring to 
FIG. 8a upon a receipt of a message from network 31 and 
particularly those associated with remote operating system 
services, an interrupt 118 may be generated and passed to a 
task generator 120 shown in FIG. 86. The task generator 120 

50 which receives the interrupt generates a proxy task for- 
warded to the scheduler 94. The proxy task assumes the 
scheduling data 100 of the message causing the interrupt and 
is subject to the same mixed processing as the tasks 
described above via the scheduler 94. Depending on its 

55 priority and other scheduling data 100, the proxy task may 
preempt the current task or might wait its turn. This proce- 
dure guarantees deterministic packet reception without 
affecting tasks on the receiving node adversely. 

Referring now to FIG. 10 in an alternate form of interrupt 

60 management, interrupts 118 from general sources such as 
communication ports and other external devices are received 
by an interrupt manager 122 prior to invoking the interrupt 
hardware on the processor 26. One exception to this is the 
timer interrupt 118' which provides a regular timer "click" 

65 for the system clock which, as described above, is used by 
the scheduler 94. The interrupt manager 122 provides a 
masking line 124 to a interrupt storage register 123, the 
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masking line allowing the interrupt manager 122 to mask or 
block other interrupts (while storing them for later 
acceptance) and communicates with an interrupt window 
counter 126 which is periodically reset by a clock 127. 

Generally, the interrupt manager 122, its masking line 5 
124, the interrupt storage register 123, the interrupt window 
counter 126 and the window timer are realized by the 
operating system 32 but as will be understood in the art may 
also be implemented by discrete circuitry such as an appli- 
cation specific integrated circuit (ASIC). 10 

Referring to FIG. 11, the interrupt manager 122 operates 
so that upon the occurrence of an interrupt as indicated by 
process block 129, all further interrupts are masked as 
indicated by process block 128. The interrupt window 
counter 126 is then checked to see if a pre-allocated window 15 
of time for processing interrupts (the interrupt window) has 
been exhausted. The interrupt window is a percentage of 
processing time or bandwidth of processor 26 reserved for 
interrupts and its exact value will depend on a number of 
variables such as processor speed, the number of external 20 
interrupts expected and how long interrupts take to be 
serviced and is selected by the control system programmer. 
In the allocation of processor resources described above, the 
interrupt period is subtracted out prior to allocation to the 
various application programs. The interrupt window counter 25 

126 is reset to its full value on a periodic basis by the clock 

127 so as to implement the appropriate percentage of 
processing time. 

At process block 130, after the masking of the interrupts 
at process block 128, the interrupt window counter 126 is 
checked to see if the amount of remaining interrupt window 
is sufficient to allow processing of the current interrupt based 
on its expected execution period. The execution periods may 
be entered by the control system programmer and keyed to 
the interrupt type and number. If sufficient time remains in 
the interrupt window, the execution period is subtracted 
from the interrupt window and, as determined by decision 
block 132, then the interrupt manager 122 proceeds to 
process block 134. At process block 134 the interrupts 118 
are re-enabled via masking line 124 and at process block 
136, the current interrupt is processed. The time taken to 
process the interrupts monitored and at its conclusion the 
interrupt window is corrected by adding the estimated 
execution period and subtracting the actual monitored 
execution period. 45 

By re-enabling the interrupts at process block 134, nested 
interrupts may occur which may also be subject to the 
processing described with respect to process block 129. 
Nested interrupting is possible because prior to each nested 5Q 
interrupt, the estimated execution period will be cleared 
against the interrupt window. 

If at decision block 132, there is inadequate time left in the 
interrupt window, then the interrupt manager 122 proceeds 
to decision block 138 where it remains until the interrupt 55 
window is reset by the clock 127. At that time, process 
blocks 134 and 136 may be executed. 

As mentioned, the interrupt window is subtracted from 
the bandwidth of the processor 26 that may be allocated to 
user tasks and therefore the allocation of bandwidth for 60 
guaranteeing the execution of user tasks is done under the 
assumption that the full interrupt window will be used by 
interrupts taking the highest priority. In this way, interrupts 
may be executed within the interrupt window without affect- 
ing guarantees for task execution. 

The above description has been that of a preferred 
embodiment of the present invention. It will occur to those 
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that practice the art that many modifications may be made 
without departing from the spirit and scope of the invention. 
In order to apprise the public of the various embodiments 
that may fall within the scope of the invention, the following 
claims are made. 

I claim: 

1. An interrupt manager for use with a processor in a 
distributed control system, the interrupt manager compris- 
ing: 

(a) interrupt reception circuitry receiving interrupt signals 
including a current interrupt; 

(b) an interrupt window counter storing an interrupt 
window indicating time available for processing of 
interrupts; 

(c) a timer refreshing the interrupt window counter at 
expiration of a window period; and 

(e) a masking circuit masking a current interrupt when the 
interrupt window counter indicates that the processing 
of the current interrupt would exceed the interrupt 
window in the current window period. 

2. The interrupt manager of claim 1 wherein the interrupt 
reception circuitry allows masking of interrupts and wherein 
the interrupt manager upon receiving the interrupt signal 
masks further interrupts until it is determined that the 
processing of the current interrupt would not exceed the 
interrupt window in the current window period. 

3. The interrupt manager of claim 1 wherein the interrupt 
manager provides an estimate of the time needed for pro- 
cessing the current interrupt and uses this estimate to change 
the value of the interrupt window when the interrupt window 
indicates that the processing of the current interrupt would 
not exceed the interrupt window. 

4. The interrupt manager of claim 1 wherein the interrupt 
manager ceases masking the current interrupt upon the 
resetting of the interrupt window counter by the timer. 

5. The interrupt manger of claim 1 including further a 
resource allocating operating system pre-allocating portions 
of the window period, excluding the maximum interrupt 
window to multiple tasks to be executed on the processor so 
as to guarantee timely execution of those tasks. 

6. The interrupt manager of claim 1 wherein the interrupt 
manager determines whether the processing of the current 
interrupt would exceed the interrupt window of the current 
window period by subtracting an estimate of the interrupt 
processing time from the interrupt window. 

7. The interrupt manager of claim 6 wherein the interrupt 
manager further monitors the execution of the current inter- 
rupt and modifies the estimate of the interrupt processing 
time according the monitoring; 

whereby the interrupt processing time is more accurately 
determined. 

8. The interrupt manager of claim 6 wherein upon 
completion of the current interrupt, the interrupt manager 
adds the estimate of the interrupt processing time to the 
interrupt window and subtracts an actual interrupt process- 
ing time from the value of the interrupt window; 

whereby later estimates of the interrupt window are more 
accurate. 

9. An interrupt manager for use with a processor in a 
distributed control system, the interrupt manager compris- 
ing: 

(a) a task scheduler receiving tasks and arranging tasks in 
a queue according to priorities for execution by the 
processor; 
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(b) a communication circuit receiving messages having a 
priority to generate a communications interrupt; and 

(c) an interrupt reception circuit communicating with the 
task scheduler and the communication circuit to receive 
communication interrupts and to generate correspond- 5 
ing proxy tasks sent to the task scheduler, the proxy 
task when executed by the processor causing the com- 
munication interrupt to be processed as a task, the 
proxy tasks having the priority of the message associ- 
ated with their communication interrupt. 
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10. The interrupt manager of claim 9 wherein the message 
priority includes a user assigned priority and a time con- 
straint value and wherein the interrupt reception circuit 
generates a proxy task having both the user assigned priority 
and the time constraint value task scheduler. 

11. The interrupt manager of claim 10 wherein the task 
scheduler schedules the task in an order that depends on both 
the user assigned priority and the time constraint value. 

* * * * * 
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